From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935092AbdEVQmt (ORCPT ); Mon, 22 May 2017 12:42:49 -0400 Received: from mail-pf0-f175.google.com ([209.85.192.175]:33700 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934585AbdEVQmo (ORCPT ); Mon, 22 May 2017 12:42:44 -0400 MIME-Version: 1.0 In-Reply-To: References: <1494912127-12890-1-git-send-email-oza.oza@broadcom.com> <1494912127-12890-2-git-send-email-oza.oza@broadcom.com> From: Oza Oza Date: Mon, 22 May 2017 22:12:43 +0530 Message-ID: Subject: Re: [PATCH v6 1/3] of/pci/dma: fix DMA configuration for PCI masters To: Arnd Bergmann Cc: Joerg Roedel , Robin Murphy , Linux IOMMU , linux-pci , Linux Kernel Mailing List , Linux ARM , devicetree@vger.kernel.org, bcm-kernel-feedback-list , Oza Pawandeep Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 18, 2017 at 12:43 AM, Arnd Bergmann wrote: > On Tue, May 16, 2017 at 7:22 AM, Oza Pawandeep wrote: >> current device framework and OF framework integration assumes >> dma-ranges in a way where memory-mapped devices define their >> dma-ranges. (child-bus-address, parent-bus-address, length). >> >> of_dma_configure is specifically written to take care of memory >> mapped devices. but no implementation exists for pci to take >> care of pcie based memory ranges. > > Hi Oza, > > I'm trying to make sense of this, but am still rather puzzled. I have > no idea what the distinction between memory-mapped devices and > pcie based devices is in your description, as PCIe is usually memory > mapped, and Linux doesn't actually support other kinds of PCIe > devices on most architectures. > >> for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI >> world dma-ranges. >> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>; >> >> this patch serves following: >> >> 1) exposes interface to the pci host driver for their >> inbound memory ranges >> >> 2) provide an interface to callers such as of_dma_get_ranges. >> so then the returned size get best possible (largest) dma_mask. >> because PCI RC drivers do not call APIs such as >> dma_set_coherent_mask() and hence rather it shows its addressing >> capabilities based on dma-ranges. >> >> for e.g. >> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>; >> we should get dev->coherent_dma_mask=0x7fffffffff. > > do you mean the coherent_dma_mask of the PCI host bridge > or an attached device here? > > If you require PCI devices to come up with an initial > coherent_dma_mask other than 0xffffffffff, there are other > problems involved. In particular, you will need to use > swiotlb, which is not supported on arm32 at the moment, > and the dma_set_mask()/dma_set_coherent_mask() > functions need to be modified. > >> + while (1) { >> + dma_ranges = of_get_property(node, "dma-ranges", &rlen); >> + >> + /* Ignore empty ranges, they imply no translation required. */ >> + if (dma_ranges && rlen > 0) >> + break; >> + >> + /* no dma-ranges, they imply no translation required. */ >> + if (!dma_ranges) >> + break; > > A missing parent dma-ranges property here should really indicate that there > is no valid translation. If we have existing cases where this happens > in DT files, we may treat it as allowing only 32-bit DMA (as we already > do for having no dma-ranges at all), but treating it the same way > as an empty dma-ranges property sounds wrong. > > Arnd Hi Arnd and Bjorn, Can you please have a look at PATCH v7 ? It addresses problem2 alone. Regards, Oza