From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grygorii Strashko via iommu Subject: Re: [PATCH v2 2/7] dma-mapping: Generalise dma_32bit_limit flag Date: Fri, 27 Jul 2018 15:41:32 -0500 Message-ID: <5a7ed608-73dd-e515-3a22-0870fd6064be@ti.com> References: <7872d914-8ea7-06e4-4a0c-489023e098d6@ti.com> <5354ef69-c54e-170b-62d4-5110dc60aa8f@arm.com> Reply-To: Grygorii Strashko Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <5354ef69-c54e-170b-62d4-5110dc60aa8f-5wv7dgnIgG8@public.gmane.org> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Robin Murphy , hch-jcswGhMUV9g@public.gmane.org, m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, sudeep.holla-5wv7dgnIgG8@public.gmane.org, frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: linux-acpi@vger.kernel.org CgpPbiAwNy8yNy8yMDE4IDAzOjExIFBNLCBSb2JpbiBNdXJwaHkgd3JvdGU6Cj4gT24gMjAxOC0w Ny0yNyA2OjQ1IFBNLCBHcnlnb3JpaSBTdHJhc2hrbyB3cm90ZToKPj4gT24gMDcvMjMvMjAxOCAw NToxNiBQTSwgUm9iaW4gTXVycGh5IHdyb3RlOgo+Pj4gV2hpbHN0IHRoZSBub3Rpb24gb2YgYW4g dXBzdHJlYW0gRE1BIHJlc3RyaWN0aW9uIGlzIG1vc3QgY29tbW9ubHkgc2Vlbgo+Pj4gaW4gUENJ IGhvc3QgYnJpZGdlcyBzYWRkbGVkIHdpdGggYSAzMi1iaXQgbmF0aXZlIGludGVyZmFjZSwgYSBt b3JlCj4+PiBnZW5lcmFsIHZlcnNpb24gb2YgdGhlIHNhbWUgaXNzdWUgY2FuIGV4aXN0IG9uIGNv bXBsZXggU29DcyB3aGVyZSBhIGJ1cwo+Pj4gb3IgcG9pbnQtdG8tcG9pbnQgaW50ZXJjb25uZWN0 IGxpbmsgZnJvbSBhIGRldmljZSdzIERNQSBtYXN0ZXIgaW50ZXJmYWNlCj4+PiB0byBhbm90aGVy IGNvbXBvbmVudCBhbG9uZyB0aGUgcGF0aCB0byBtZW1vcnkgKG9mdGVuIGFuIElPTU1VKSBtYXkg Y2FycnkKPj4+IGZld2VyIGFkZHJlc3MgYml0cyB0aGFuIHRoZSBpbnRlcmZhY2VzIGF0IGJvdGgg ZW5kcyBub21pbmFsbHkgc3VwcG9ydC4KPj4+IEluIG9yZGVyIHRvIHByb3Blcmx5IGRlYWwgd2l0 aCB0aGlzLCB0aGUgZmlyc3Qgc3RlcCBpcyB0byBleHBhbmQgdGhlCj4+PiBkbWFfMzJiaXRfbGlt aXQgZmxhZyBpbnRvIGFuIGFyYml0cmFyeSBtYXNrLgo+Pj4KPj4+IFRvIG1pbmltaXNlIHRoZSBp bXBhY3Qgb24gZXhpc3RpbmcgY29kZSwgd2UnbGwgbWFrZSBzdXJlIHRvIG9ubHkKPj4+IGNvbnNp ZGVyIHRoaXMgbmV3IG1hc2sgdmFsaWQgaWYgc2V0LiBUaGF0IG1ha2VzIHNlbnNlIGFueXdheSwg c2luY2UgYQo+Pj4gbWFzayBvZiB6ZXJvIHdvdWxkIHJlcHJlc2VudCBETUEgbm90IGJlaW5nIHdp cmVkIHVwIGF0IGFsbCwgYW5kIHRoYXQKPj4+IHdvdWxkIGJlIGJldHRlciBoYW5kbGVkIGJ5IG5v dCBwcm92aWRpbmcgdmFsaWQgb3BzIGluIHRoZSBmaXJzdCBwbGFjZS4KPj4+Cj4+PiBTaWduZWQt b2ZmLWJ5OiBSb2JpbiBNdXJwaHkgPHJvYmluLm11cnBoeUBhcm0uY29tPgo+Pgo+PiBJJ2QgbGlr ZSB0byBub3RlIGFib3V0IHNvbWUgcG9zc2libGUgaXNzdWUgcmVsYXRlZCB0byB0aGlzIGNoYW5n ZS4KPj4KPj4gVGhlcmUgYXJlIHNvbWUgcGxhY2VzIGluIGtlcm5lbCB3aGVyZSBwYXJlbnQgRE1B IGNvbmZpZ3VyYXRpb24gaXMgCj4+IGNvcGllZCB0byB0aGUgbWFudWFsbHkgY3JlYXRlZCBjaGls ZCBkZXZpY2VzLCBsaWtlOgo+PiBtZmQtY29yZS5jCj4+IG1mZF9hZGRfZGV2aWNlKCkKPj4gwqDC oMKgwqDCoHBkZXYtPmRldi5wYXJlbnQgPSBwYXJlbnQ7Cj4+IMKgwqDCoMKgwqBwZGV2LT5kZXYu dHlwZSA9ICZtZmRfZGV2X3R5cGU7Cj4+IMKgwqDCoMKgwqBwZGV2LT5kZXYuZG1hX21hc2sgPSBw YXJlbnQtPmRtYV9tYXNrOwo+PiDCoMKgwqDCoMKgcGRldi0+ZGV2LmRtYV9wYXJtcyA9IHBhcmVu dC0+ZG1hX3Bhcm1zOwo+PiDCoMKgwqDCoMKgcGRldi0+ZGV2LmNvaGVyZW50X2RtYV9tYXNrID0g cGFyZW50LT5jb2hlcmVudF9kbWFfbWFzazsKPj4KPj4gQWRkaW5nIG9yIGNoYW5naW5nIGdlbmVy aWMgRE1BIGRldmljZSBwcm9wZXJ0aWVzIG1pZ2h0IGFmZmVjdCBvbiBzdWNoCj4+IHN1YnN5c3Rl bXMvZHJpdmVycy4gSGF2ZSB5b3UgY29uc2lkZXJlZCBzdWNoIGNhc2VzPwo+IAo+IFllcywgdGhh dCdzIGEgbG92ZWx5IGV4YW1wbGUgb2Ygd2hhdCBJIGNsYXNzIGFzICJidXMgY29kZSIgY3JlYXRp bmcgYSAKPiBjaGlsZCBkZXZpY2UgYW5kIGluaXRpYWxpc2luZyBpdHMgRE1BIHBhcmFtZXRlcnMg YXBwcm9wcmlhdGVseS4gVGhlIAo+IHN1YmRldmljZSBnb2VzIG9uIHRvIGdldCBhc3NvY2lhdGVk IHdpdGggYW4gT0Ygbm9kZSBvciBBQ1BJIGNvbXBhbmlvbiwgCj4gc28gd2hlbiB0aGUgc3ViZHJp dmVyIGZvciB0aGF0IGZ1bmN0aW9uIGJpbmRzIGl0IHNob3VsZCBnbyB0aHJvdWdoIGl0cyAKPiBv d24gZG1hX2NvbmZpZ3VyZSgpIHByb2Nlc3MgYW5kIHBpY2sgdXAgYW55IGZ1cnRoZXIgcHJvcGVy dGllcyBhY2NvcmRpbmdseS4KCklkZWFsbHkgOyksIGJ1dCBpbiByZWFsaXR5IC0gZGV2LT5vZl9u b2RlIG5vdCBhbHdheXMgaW5pdGlhbGl6ZWQgZm9yIGNoaWxkIGRldmljZXMgOigKCj4gCj4gQ29k ZSB3aGljaCBqdXN0IHRyaWVzIHRvIGNvcHkgdGhlIERNQSBjb25maWd1cmF0aW9uIGZyb20gYW4g ZXhpc3RpbmcgCj4gZGV2aWNlIHRvIGEgbmV3IG9uZSBoYXMgbmV2ZXIgd29ya2VkIHByb3Blcmx5 LCBiZWNhdXNlIHRoZXJlIGlzIG9mdGVuIAo+IGFkZGl0aW9uYWwgRE1BIGNvbmZpZ3VyYXRpb24g aW4gYXJjaGRhdGEgYW5kIG90aGVyIHBsYWNlcyBpdCBjYW5ub3QgCj4gcG9zc2libHkga25vdyBh Ym91dC4gTGFzdCB0aW1lIEkgbG9va2VkIHRoZXJlIHdlcmUgc3RpbGwgc29tZSBzcGVjaWZpYyAK PiBoYWNrcyBpbiB0aGUgVVNCIGxheWVyIGluIG9yZGVyIHRvIGludGVyYWN0IGNvcnJlY3RseSB3 aXRoIHRoZSBibG9jayAKPiBsYXllciBib3VuY2UgbGltaXQsIGJ1dCBJIHRoaW5rIGFueXRoaW5n IHRydWx5IHdyb25nIGhhcyBiZWVuIG1vcmUgb3IgCj4gbGVzcyBmbHVzaGVkIG91dCBieSBub3cg KHRoZSBETUEgb3BzIGNoYW5nZXMgZm9yIGFybTY0IEFDUEkgc3VwcG9ydCAKPiBjYXVnaHQgYSBm YWlyIGZldyBJSVJDKS4KClllcC4gRm9yIHVzYiBJIHdvdWxkbid0IGNhbGwgaXQgaGFjayAoZG1h IGNvbnRyb2xsZXIgZGV2aWNlIHdhcyBpbnRyb2R1Y2VkCnRvIGF2b2lkIERNQSBwcm9wcyBjb3B5 aW5nKS4KClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4KCi0tIApyZWdhcmRzLAotZ3J5Z29yaWkK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaW9tbXUgbWFp bGluZyBsaXN0CmlvbW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnCmh0dHBzOi8vbGlzdHMu bGludXhmb3VuZGF0aW9uLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvbW11 From mboxrd@z Thu Jan 1 00:00:00 1970 From: grygorii.strashko@ti.com (Grygorii Strashko) Date: Fri, 27 Jul 2018 15:41:32 -0500 Subject: [PATCH v2 2/7] dma-mapping: Generalise dma_32bit_limit flag In-Reply-To: <5354ef69-c54e-170b-62d4-5110dc60aa8f@arm.com> References: <7872d914-8ea7-06e4-4a0c-489023e098d6@ti.com> <5354ef69-c54e-170b-62d4-5110dc60aa8f@arm.com> Message-ID: <5a7ed608-73dd-e515-3a22-0870fd6064be@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 07/27/2018 03:11 PM, Robin Murphy wrote: > On 2018-07-27 6:45 PM, Grygorii Strashko wrote: >> On 07/23/2018 05:16 PM, Robin Murphy wrote: >>> Whilst the notion of an upstream DMA restriction is most commonly seen >>> in PCI host bridges saddled with a 32-bit native interface, a more >>> general version of the same issue can exist on complex SoCs where a bus >>> or point-to-point interconnect link from a device's DMA master interface >>> to another component along the path to memory (often an IOMMU) may carry >>> fewer address bits than the interfaces at both ends nominally support. >>> In order to properly deal with this, the first step is to expand the >>> dma_32bit_limit flag into an arbitrary mask. >>> >>> To minimise the impact on existing code, we'll make sure to only >>> consider this new mask valid if set. That makes sense anyway, since a >>> mask of zero would represent DMA not being wired up at all, and that >>> would be better handled by not providing valid ops in the first place. >>> >>> Signed-off-by: Robin Murphy >> >> I'd like to note about some possible issue related to this change. >> >> There are some places in kernel where parent DMA configuration is >> copied to the manually created child devices, like: >> mfd-core.c >> mfd_add_device() >> ?????pdev->dev.parent = parent; >> ?????pdev->dev.type = &mfd_dev_type; >> ?????pdev->dev.dma_mask = parent->dma_mask; >> ?????pdev->dev.dma_parms = parent->dma_parms; >> ?????pdev->dev.coherent_dma_mask = parent->coherent_dma_mask; >> >> Adding or changing generic DMA device properties might affect on such >> subsystems/drivers. Have you considered such cases? > > Yes, that's a lovely example of what I class as "bus code" creating a > child device and initialising its DMA parameters appropriately. The > subdevice goes on to get associated with an OF node or ACPI companion, > so when the subdriver for that function binds it should go through its > own dma_configure() process and pick up any further properties accordingly. Ideally ;), but in reality - dev->of_node not always initialized for child devices :( > > Code which just tries to copy the DMA configuration from an existing > device to a new one has never worked properly, because there is often > additional DMA configuration in archdata and other places it cannot > possibly know about. Last time I looked there were still some specific > hacks in the USB layer in order to interact correctly with the block > layer bounce limit, but I think anything truly wrong has been more or > less flushed out by now (the DMA ops changes for arm64 ACPI support > caught a fair few IIRC). Yep. For usb I wouldn't call it hack (dma controller device was introduced to avoid DMA props copying). Thanks for your comments. -- regards, -grygorii