From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> To: Robin Murphy <robin.murphy@arm.com> Cc: Nate Watterson <nwatters@codeaurora.org>, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>, Hanjun Guo <hanjun.guo@linaro.org>, Feng Kan <fkan@apm.com>, Jon Masters <jcm@redhat.com>, Robert Moore <robert.moore@intel.com>, Zhang Rui <rui.zhang@intel.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net> Subject: Re: [PATCH 0/4] ACPI: DMA ranges management Date: Fri, 28 Jul 2017 15:09:56 +0100 [thread overview] Message-ID: <20170728140956.GA21569@red-moon> (raw) In-Reply-To: <eb81a7c6-b62b-8e02-8f22-a7fda7e403ce@arm.com> On Fri, Jul 28, 2017 at 02:08:01PM +0100, Robin Murphy wrote: [...] > >>> To ensure that dma_set_mask() and friends actually respect _DMA, would > >>> you consider introducing a dma_supported() callback to check the input > >>> dma_mask against the FW defined limits? This would end up aggressively > >>> clipping the dma_mask to 32-bits for devices like the above if the _DMA > >>> limit was less than 64-bits, but that is probably preferable to the > >>> controller accessing unintended addresses. > >>> > >>> Also, how would you feel about adding support for the IORT named_node > >>> memory_address_limit field? > >> > >> We will certainly need that for some platform devices, so if you fancy > >> giving it a go before Lorenzo or I get there, feel free! > > > > I can do it for v2 but I would like to understand why using _DMA is > > not good enough for named components - having two bindings describing > > the same thing is not ideal and I'd rather avoid it - if there is > > a reason I am happy to add the necessary code. > > My interpretation of "_DMA is only defined under devices that represent > buses." (ACPI 6.0, section 6.2.4) is that "devices that represent buses" > are those that have other device objects as children. Well if that was the case we would not be able to use _DMA for eg PNP0A03 PCI host bridges that have no child ACPI devices, which defeats the whole purpose of what I am doing. The question here is what the _DMA object binding exactly means when it refers to a "bus" and that's something I will figure out (and possibly change) ASAP. > In other words (excuse my novice pseudo-ASL), this would be valid: > > Scope(_SB) > { > Device (Bus) > { > ... > Method (_DMA ... ) > Device (Dev1) > { > ... > } > } > } > > but this should be invalid: > > Scope(_SB) > { > Device (Dev2) > { > ... > Method (_DMA ... ) > } > } Not sure about that (see above) and I agree that's what needs clarification. > Thus in the case where Dev2 is wired directly to an SMMU input, but > fewer address bits are wired up between the two than both the device and > SMMU interfaces are capable of, memory address limit is enough to > describe that without having to insert a fake "bus" object above it just > to hold the _DMA method. BTW, how would you describe that in DT ? A "dma-ranges" property in the device DT node right ? Arguably "dma-ranges" was not meant to be used like that either ;-) Long and short of it is: I do not like having two ways of describing the same thing. I agree that the _DMA object usage requires clarifications from a spec point of view but I want to do that before plugging in code that may use bindings inconsistently. I will flag this up at ACPI spec level as soon as possible and get this sorted. Thanks, Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 0/4] ACPI: DMA ranges management Date: Fri, 28 Jul 2017 15:09:56 +0100 [thread overview] Message-ID: <20170728140956.GA21569@red-moon> (raw) In-Reply-To: <eb81a7c6-b62b-8e02-8f22-a7fda7e403ce@arm.com> On Fri, Jul 28, 2017 at 02:08:01PM +0100, Robin Murphy wrote: [...] > >>> To ensure that dma_set_mask() and friends actually respect _DMA, would > >>> you consider introducing a dma_supported() callback to check the input > >>> dma_mask against the FW defined limits? This would end up aggressively > >>> clipping the dma_mask to 32-bits for devices like the above if the _DMA > >>> limit was less than 64-bits, but that is probably preferable to the > >>> controller accessing unintended addresses. > >>> > >>> Also, how would you feel about adding support for the IORT named_node > >>> memory_address_limit field? > >> > >> We will certainly need that for some platform devices, so if you fancy > >> giving it a go before Lorenzo or I get there, feel free! > > > > I can do it for v2 but I would like to understand why using _DMA is > > not good enough for named components - having two bindings describing > > the same thing is not ideal and I'd rather avoid it - if there is > > a reason I am happy to add the necessary code. > > My interpretation of "_DMA is only defined under devices that represent > buses." (ACPI 6.0, section 6.2.4) is that "devices that represent buses" > are those that have other device objects as children. Well if that was the case we would not be able to use _DMA for eg PNP0A03 PCI host bridges that have no child ACPI devices, which defeats the whole purpose of what I am doing. The question here is what the _DMA object binding exactly means when it refers to a "bus" and that's something I will figure out (and possibly change) ASAP. > In other words (excuse my novice pseudo-ASL), this would be valid: > > Scope(_SB) > { > Device (Bus) > { > ... > Method (_DMA ... ) > Device (Dev1) > { > ... > } > } > } > > but this should be invalid: > > Scope(_SB) > { > Device (Dev2) > { > ... > Method (_DMA ... ) > } > } Not sure about that (see above) and I agree that's what needs clarification. > Thus in the case where Dev2 is wired directly to an SMMU input, but > fewer address bits are wired up between the two than both the device and > SMMU interfaces are capable of, memory address limit is enough to > describe that without having to insert a fake "bus" object above it just > to hold the _DMA method. BTW, how would you describe that in DT ? A "dma-ranges" property in the device DT node right ? Arguably "dma-ranges" was not meant to be used like that either ;-) Long and short of it is: I do not like having two ways of describing the same thing. I agree that the _DMA object usage requires clarifications from a spec point of view but I want to do that before plugging in code that may use bindings inconsistently. I will flag this up at ACPI spec level as soon as possible and get this sorted. Thanks, Lorenzo
next prev parent reply other threads:[~2017-07-28 14:09 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-20 14:45 [PATCH 0/4] ACPI: DMA ranges management Lorenzo Pieralisi 2017-07-20 14:45 ` Lorenzo Pieralisi 2017-07-20 14:45 ` [PATCH 1/4] ACPI: Allow _DMA method in walk resources Lorenzo Pieralisi 2017-07-20 14:45 ` Lorenzo Pieralisi 2017-07-20 14:45 ` Lorenzo Pieralisi 2017-07-20 15:48 ` Moore, Robert 2017-07-20 15:48 ` Moore, Robert 2017-07-20 15:48 ` Moore, Robert 2017-07-20 15:50 ` Moore, Robert 2017-07-20 15:50 ` Moore, Robert 2017-07-20 15:50 ` Moore, Robert 2017-07-21 10:20 ` Lorenzo Pieralisi 2017-07-21 10:20 ` Lorenzo Pieralisi 2017-07-21 10:20 ` Lorenzo Pieralisi 2017-07-20 14:45 ` [PATCH 2/4] ACPI: Make acpi_dev_get_resources() method agnostic Lorenzo Pieralisi 2017-07-20 14:45 ` Lorenzo Pieralisi 2017-07-21 22:05 ` Rafael J. Wysocki 2017-07-21 22:05 ` Rafael J. Wysocki 2017-07-24 9:22 ` Lorenzo Pieralisi 2017-07-24 9:22 ` Lorenzo Pieralisi 2017-07-25 9:15 ` Lorenzo Pieralisi 2017-07-25 9:15 ` Lorenzo Pieralisi 2017-07-26 0:23 ` Rafael J. Wysocki 2017-07-26 0:23 ` Rafael J. Wysocki 2017-07-20 14:45 ` [PATCH 3/4] ACPI: Introduce DMA ranges parsing Lorenzo Pieralisi 2017-07-20 14:45 ` Lorenzo Pieralisi 2017-07-21 22:15 ` Rafael J. Wysocki 2017-07-21 22:15 ` Rafael J. Wysocki 2017-07-24 10:40 ` Lorenzo Pieralisi 2017-07-24 10:40 ` Lorenzo Pieralisi 2017-07-24 18:42 ` Rafael J. Wysocki 2017-07-24 18:42 ` Rafael J. Wysocki 2017-07-24 18:42 ` Rafael J. Wysocki 2017-07-25 9:06 ` Lorenzo Pieralisi 2017-07-25 9:06 ` Lorenzo Pieralisi 2017-07-25 9:06 ` Lorenzo Pieralisi 2017-07-26 0:27 ` Rafael J. Wysocki 2017-07-26 0:27 ` Rafael J. Wysocki 2017-07-26 0:27 ` Rafael J. Wysocki 2017-07-20 14:45 ` [PATCH 4/4] ACPI: Make acpi_dma_configure() DMA regions aware Lorenzo Pieralisi 2017-07-20 14:45 ` Lorenzo Pieralisi 2017-07-26 14:46 ` [PATCH 0/4] ACPI: DMA ranges management Nate Watterson 2017-07-26 14:46 ` Nate Watterson 2017-07-26 15:05 ` Robin Murphy 2017-07-26 15:05 ` Robin Murphy 2017-07-26 15:35 ` Lorenzo Pieralisi 2017-07-26 15:35 ` Lorenzo Pieralisi 2017-07-26 16:39 ` Nate Watterson 2017-07-26 16:39 ` Nate Watterson 2017-07-28 13:08 ` Robin Murphy 2017-07-28 13:08 ` Robin Murphy 2017-07-28 14:09 ` Lorenzo Pieralisi [this message] 2017-07-28 14:09 ` Lorenzo Pieralisi 2017-07-28 15:55 ` Robin Murphy 2017-07-28 15:55 ` Robin Murphy 2017-07-31 8:56 ` Lorenzo Pieralisi 2017-07-31 8:56 ` Lorenzo Pieralisi
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=20170728140956.GA21569@red-moon \ --to=lorenzo.pieralisi@arm.com \ --cc=fkan@apm.com \ --cc=hanjun.guo@linaro.org \ --cc=jcm@redhat.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=nwatters@codeaurora.org \ --cc=rjw@rjwysocki.net \ --cc=robert.moore@intel.com \ --cc=robin.murphy@arm.com \ --cc=rui.zhang@intel.com \ --cc=will.deacon@arm.com \ /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.