From: Murali Karicheri <m-karicheri2@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: <linux-arm-kernel@lists.infradead.org>, <vinod.koul@intel.com>,
<gregkh@linuxfoundation.org>, <linux-kernel@vger.kernel.org>,
<dmaengine@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<bhelgaas@google.com>, <will.deacon@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [RFC PATCH 1/2] common: dma-mapping: introduce dma_get_parent_cfg() helper
Date: Thu, 18 Dec 2014 14:02:17 -0500 [thread overview]
Message-ID: <549324B9.2030506@ti.com> (raw)
In-Reply-To: <2935351.ba8Au9y4fE@wuerfel>
On 12/17/2014 07:09 PM, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 18:24:43 Murali Karicheri wrote:
>> On 12/17/2014 04:56 PM, Arnd Bergmann wrote:
>>> On Wednesday 17 December 2014 13:02:23 Murali Karicheri wrote:
>>>
>>> What's wrong with using arch_setup_dma_ops() from PCI as suggested
>>> previously?
>>>
>
> +Will Deacon
>
>> I had originally written a code based on that line as below. But
>> dma-ranges property is also used by ppc and other architectures in the
>> pci device DT node. So I wasn't sure how this code impact PCI driver
>> functionality on those platforms. Hence used a simpler change as all
>> that is needed for keystone is to get the dma_pfn_offset rightly set in
>> the pci slave device.
>
> But in your patch, you don't call arch_setup_dma_ops() at all.
>
>> Initially I had a function implemented as below for this in of_pci.c.
>>
>> + * of_pci_dma_configure - Setup DMA configuration for a pci device
>> + * @dev: pci device to apply DMA configuration
>> + *
>> + * Try to get devices's DMA configuration from DT and update it
>> + * accordingly. This is a similar to of_dma_configure() for platform
>> + * devices.
>> + *
>> + */
>> +void of_pci_dma_configure(struct pci_dev *dev)
>> +{
>> + struct device *host_bridge, *parent;
>> + struct pci_bus *bus = dev->bus;
>> + u64 dma_addr, paddr, size;
>> + int ret;
>> +
>> + while (!pci_is_root_bus(bus))
>> + bus = bus->parent;
>> + host_bridge = bus->bridge;
>> +
>> + parent = host_bridge->parent;
>> + if (parent->of_node) {
>
> so far it looks good, although we may want to introduce
> a helper function to get the of_node.
Will add
>
>> + /*
>> + * if dma-coherent property exist, call arch hook to setup
>> + * dma coherent operations.
>> + */
>> + if (of_dma_is_coherent(parent->of_node)) {
>> + set_arch_dma_coherent_ops(&dev->dev);
>> + dev_info(&dev->dev, "device is dma coherent\n");
>> + }
>
> set_arch_dma_coherent_ops no longer exists. Just keep the flag in a
> local variable
Ok.
>
>> + /*
>> + * if dma-ranges property doesn't exist - just return else
>> + * setup the dma offset
>> + */
>> + ret = of_dma_get_range(parent->of_node,&dma_addr,
>> &paddr,&size);
>> + if (ret< 0) {
>> + dev_info(&dev->dev, "no dma range information to
>> setup\n");
>> + printk("no dma range information to setup\n");
>> + return;
>> + }
>> +
>> + /* DMA ranges found. Calculate and set dma_pfn_offset */
>> + dev->dev.dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>> + dev_info(&dev->dev, "dma_pfn_offset(%#08lx)\n",
>> dev->dev.dma_pfn_offset);
>
> Same for the offset and size here, then pass all of the above into
> arch_setup_dma_ops. This is also where we need to hook up the iommu
> support once we decide how to make that work with the ARM SMMU.
Ok. I will make this similar to of_dma_configure() that can be called
from pci/probe.c
Murali
>
> Will, I think we may have a problem on ARM64 now, since we only replaced
> set_arch_dma_coherent_ops on ARM32 but not ARM64. Can you send a fix for
> this? Without that, we don't have any coherent operations on ARM64 any
> more, unless I'm missing something.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Murali Karicheri
Linux Kernel, Texas Instruments
WARNING: multiple messages have this Message-ID (diff)
From: m-karicheri2@ti.com (Murali Karicheri)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/2] common: dma-mapping: introduce dma_get_parent_cfg() helper
Date: Thu, 18 Dec 2014 14:02:17 -0500 [thread overview]
Message-ID: <549324B9.2030506@ti.com> (raw)
In-Reply-To: <2935351.ba8Au9y4fE@wuerfel>
On 12/17/2014 07:09 PM, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 18:24:43 Murali Karicheri wrote:
>> On 12/17/2014 04:56 PM, Arnd Bergmann wrote:
>>> On Wednesday 17 December 2014 13:02:23 Murali Karicheri wrote:
>>>
>>> What's wrong with using arch_setup_dma_ops() from PCI as suggested
>>> previously?
>>>
>
> +Will Deacon
>
>> I had originally written a code based on that line as below. But
>> dma-ranges property is also used by ppc and other architectures in the
>> pci device DT node. So I wasn't sure how this code impact PCI driver
>> functionality on those platforms. Hence used a simpler change as all
>> that is needed for keystone is to get the dma_pfn_offset rightly set in
>> the pci slave device.
>
> But in your patch, you don't call arch_setup_dma_ops() at all.
>
>> Initially I had a function implemented as below for this in of_pci.c.
>>
>> + * of_pci_dma_configure - Setup DMA configuration for a pci device
>> + * @dev: pci device to apply DMA configuration
>> + *
>> + * Try to get devices's DMA configuration from DT and update it
>> + * accordingly. This is a similar to of_dma_configure() for platform
>> + * devices.
>> + *
>> + */
>> +void of_pci_dma_configure(struct pci_dev *dev)
>> +{
>> + struct device *host_bridge, *parent;
>> + struct pci_bus *bus = dev->bus;
>> + u64 dma_addr, paddr, size;
>> + int ret;
>> +
>> + while (!pci_is_root_bus(bus))
>> + bus = bus->parent;
>> + host_bridge = bus->bridge;
>> +
>> + parent = host_bridge->parent;
>> + if (parent->of_node) {
>
> so far it looks good, although we may want to introduce
> a helper function to get the of_node.
Will add
>
>> + /*
>> + * if dma-coherent property exist, call arch hook to setup
>> + * dma coherent operations.
>> + */
>> + if (of_dma_is_coherent(parent->of_node)) {
>> + set_arch_dma_coherent_ops(&dev->dev);
>> + dev_info(&dev->dev, "device is dma coherent\n");
>> + }
>
> set_arch_dma_coherent_ops no longer exists. Just keep the flag in a
> local variable
Ok.
>
>> + /*
>> + * if dma-ranges property doesn't exist - just return else
>> + * setup the dma offset
>> + */
>> + ret = of_dma_get_range(parent->of_node,&dma_addr,
>> &paddr,&size);
>> + if (ret< 0) {
>> + dev_info(&dev->dev, "no dma range information to
>> setup\n");
>> + printk("no dma range information to setup\n");
>> + return;
>> + }
>> +
>> + /* DMA ranges found. Calculate and set dma_pfn_offset */
>> + dev->dev.dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
>> + dev_info(&dev->dev, "dma_pfn_offset(%#08lx)\n",
>> dev->dev.dma_pfn_offset);
>
> Same for the offset and size here, then pass all of the above into
> arch_setup_dma_ops. This is also where we need to hook up the iommu
> support once we decide how to make that work with the ARM SMMU.
Ok. I will make this similar to of_dma_configure() that can be called
from pci/probe.c
Murali
>
> Will, I think we may have a problem on ARM64 now, since we only replaced
> set_arch_dma_coherent_ops on ARM32 but not ARM64. Can you send a fix for
> this? Without that, we don't have any coherent operations on ARM64 any
> more, unless I'm missing something.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Murali Karicheri
Linux Kernel, Texas Instruments
next prev parent reply other threads:[~2014-12-18 19:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 18:02 [RFC PATCH 0/2] PCI: get DMA configuration from parent device Murali Karicheri
2014-12-17 18:02 ` Murali Karicheri
2014-12-17 18:02 ` [RFC PATCH 1/2] common: dma-mapping: introduce dma_get_parent_cfg() helper Murali Karicheri
2014-12-17 18:02 ` Murali Karicheri
2014-12-17 21:56 ` Arnd Bergmann
2014-12-17 21:56 ` Arnd Bergmann
2014-12-17 23:24 ` Murali Karicheri
2014-12-17 23:24 ` Murali Karicheri
2014-12-18 0:09 ` Arnd Bergmann
2014-12-18 0:09 ` Arnd Bergmann
2014-12-18 17:20 ` Catalin Marinas
2014-12-18 17:20 ` Catalin Marinas
2014-12-21 10:42 ` Will Deacon
2014-12-21 10:42 ` Will Deacon
2014-12-18 19:02 ` Murali Karicheri [this message]
2014-12-18 19:02 ` Murali Karicheri
2014-12-17 18:02 ` [RFC PATCH 2/2] PCI: get device dma configuration from parent Murali Karicheri
2014-12-17 18:02 ` Murali Karicheri
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=549324B9.2030506@ti.com \
--to=m-karicheri2@ti.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=dmaengine@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=vinod.koul@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: link
Be 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.