From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> To: Andreas Herrmann <andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org> Cc: Olav Haugan <ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" <devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org> Subject: Re: [PATCH v2] documentation: iommu: add description of ARM System MMU binding Date: Mon, 13 May 2013 10:58:46 +0100 [thread overview] Message-ID: <20130513095846.GC29814@mudshark.cambridge.arm.com> (raw) In-Reply-To: <20130513095020.GB10369@alberich> On Mon, May 13, 2013 at 10:50:20AM +0100, Andreas Herrmann wrote: > Hi Will, Hi Andreas, > so far, I thought, that this proposal is fine. After I have tried to > make use of the binding I have some points that might need further > disucssion. Sure, although I've been using the binding without issues so it would be interesting to understand your use-case and why it's raising problems. > Olav already asked (in another thread) how to model the mapping of > stream IDs to contexts for master devices that support multiple > contexts. I doubt that this is fully covered yet. Yeah, I've been meaning to reply to that. Given the way that the IOMMU API is structure in Linux, I don't think having multiple stream IDs per (struct) device, where each StreamID points at a different context (and therefore address space) makes much sense. It also doesn't solve the more general problem where StreamIDs for a device might have different SMMUs downstream. To solve this, I think it is better to treat the device as having multiple struct device instances, and managing the mappings in the device driver. For most devices, I'd expect a single context to be enough. This is certainly the case for device virtualisation at stage-2 and DMA at stage-1. > I also think that it is more useful to move the stream-id property to > the device node of a master device. (It's a characteristic of the > master device not of the SMMU.) Currently with multiple stream IDs per > master device you have repeated entries in the mmu-master property. The problem with that approach is how to handle StreamID remastering. This can and will happen, so the StreamID for a device is actually a property of both the device *and* a particular point in the bus topology. Putting this information in the device nodes will drag topology information all over the place and I don't think it will make things clearer to read or easier to parse. > But all that is needed is to point (once) to each mmu-master in the > SMMU device node. Then you should be able to look up the corresponding > stream IDs in the device node for each mmu-master. Again, you also need to tie in topology information if you go down this route. Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2] documentation: iommu: add description of ARM System MMU binding Date: Mon, 13 May 2013 10:58:46 +0100 [thread overview] Message-ID: <20130513095846.GC29814@mudshark.cambridge.arm.com> (raw) In-Reply-To: <20130513095020.GB10369@alberich> On Mon, May 13, 2013 at 10:50:20AM +0100, Andreas Herrmann wrote: > Hi Will, Hi Andreas, > so far, I thought, that this proposal is fine. After I have tried to > make use of the binding I have some points that might need further > disucssion. Sure, although I've been using the binding without issues so it would be interesting to understand your use-case and why it's raising problems. > Olav already asked (in another thread) how to model the mapping of > stream IDs to contexts for master devices that support multiple > contexts. I doubt that this is fully covered yet. Yeah, I've been meaning to reply to that. Given the way that the IOMMU API is structure in Linux, I don't think having multiple stream IDs per (struct) device, where each StreamID points at a different context (and therefore address space) makes much sense. It also doesn't solve the more general problem where StreamIDs for a device might have different SMMUs downstream. To solve this, I think it is better to treat the device as having multiple struct device instances, and managing the mappings in the device driver. For most devices, I'd expect a single context to be enough. This is certainly the case for device virtualisation at stage-2 and DMA at stage-1. > I also think that it is more useful to move the stream-id property to > the device node of a master device. (It's a characteristic of the > master device not of the SMMU.) Currently with multiple stream IDs per > master device you have repeated entries in the mmu-master property. The problem with that approach is how to handle StreamID remastering. This can and will happen, so the StreamID for a device is actually a property of both the device *and* a particular point in the bus topology. Putting this information in the device nodes will drag topology information all over the place and I don't think it will make things clearer to read or easier to parse. > But all that is needed is to point (once) to each mmu-master in the > SMMU device node. Then you should be able to look up the corresponding > stream IDs in the device node for each mmu-master. Again, you also need to tie in topology information if you go down this route. Will
next prev parent reply other threads:[~2013-05-13 9:58 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-04-12 18:02 [PATCH v2] documentation: iommu: add description of ARM System MMU binding Will Deacon 2013-04-12 18:02 ` Will Deacon 2013-05-13 9:50 ` Andreas Herrmann 2013-05-13 9:50 ` Andreas Herrmann 2013-05-13 9:58 ` Will Deacon [this message] 2013-05-13 9:58 ` Will Deacon 2013-05-13 10:41 ` Andreas Herrmann 2013-05-13 10:41 ` Andreas Herrmann 2013-05-17 20:16 ` Andreas Herrmann 2013-05-17 20:16 ` Andreas Herrmann 2013-05-20 10:18 ` Will Deacon 2013-05-20 10:18 ` Will Deacon [not found] ` <20130520101841.GK31359-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org> 2013-05-21 10:25 ` Andreas Herrmann 2013-05-21 10:25 ` Andreas Herrmann 2013-05-21 17:33 ` Will Deacon 2013-05-21 17:33 ` Will Deacon [not found] ` <20130521173357.GA26251-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org> 2013-05-21 18:35 ` Andreas Herrmann 2013-05-21 18:35 ` Andreas Herrmann
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130513095846.GC29814@mudshark.cambridge.arm.com \ --to=will.deacon-5wv7dgnigg8@public.gmane.org \ --cc=andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \ --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \ --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=ohaugan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \ --cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.