From: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>,
Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
nsekhar-l0cyMroinI0@public.gmane.org
Subject: Re: [PATCH] of: Devices with pci_epf_bus_type require DMA configuration
Date: Mon, 23 Oct 2017 11:13:23 +0530 [thread overview]
Message-ID: <3599d3e2-d496-eac3-7179-2d1795fc059d@ti.com> (raw)
In-Reply-To: <cae4b8e9-9944-6482-c12c-8ce87aea1487-5wv7dgnIgG8@public.gmane.org>
Hi,
On Wednesday 11 October 2017 10:15 PM, Robin Murphy wrote:
> On 11/10/17 09:00, Kishon Vijay Abraham I wrote:
>> pci-epc-core.c invokes of_dma_configure in order to configure
>> the coherent_dma_mask/dma_mask of endpoint function device. This is
>> required for dma_alloc_coherent to succeed in pci function driver
>> (pci-epf-test.c). However after
>> commit 723288836628bc1c08 ("of: restrict DMA configuration"),
>> of_dma_configure doesn't configure the coherent_dma_mask/dma_mask
>> of endpoint function device (since it doesn't have dma-ranges
>> property), resulting in dma_alloc_coherent in pci endpoint function
>> driver to to fail. Fix it by making sure of_dma_configure configures
>> coherent_dma_mask/dma_mask irrespective of whether the node has
>> dma-ranges property or not.
>
> Frankly, what the endpoint stuff is doing looks wrong anyway. As I
> understand it, the endpoint functions aren't real devices, just a
> partitioning of resources - the only piece of hardware actually doing
> DMA is the EPC itself, which should already have been configured
> appropriately as a platform device.
EPF devices use EPC devices which in turn use the actual platform device for
configuring the hardware. IMO the devices in one layer shouldn't have to
explicitly use devices in another layer other than using clearly defined API's.
Here platform_device is the bottom later, above which is epc_device and on top
is epf_device.
The idea is just by doing the initial setup in the framework, the epf driver be
able to use APIs like dma_alloc_coherent using it's own *device* rather than
the EPC's "device".
>
> It seems to me that the EPF BAR allocations should just be using the EPC
> device directly, rather than trying to pretend the EPFs are distinct DMA
> masters.
>
> Furthermore, now that I've looked:
>
>> dma_addr_t phys_addr;
>
> please no :(
>
> (I can easily think of more than one system with an EP-capable DWC PCIe
> block integrated behind an IOMMU)
hmm.. haven't used IOMMU but won't setting up parent-child relationship between
EPC and EPF help in the case of IOMMU?
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-10-23 5:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 8:00 [PATCH] of: Devices with pci_epf_bus_type require DMA configuration Kishon Vijay Abraham I
2017-10-11 13:07 ` Rob Herring
[not found] ` <20171011080041.12918-1-kishon-l0cyMroinI0@public.gmane.org>
2017-10-11 16:45 ` Robin Murphy
[not found] ` <cae4b8e9-9944-6482-c12c-8ce87aea1487-5wv7dgnIgG8@public.gmane.org>
2017-10-23 5:43 ` Kishon Vijay Abraham I [this message]
2017-10-23 6:31 ` Christoph Hellwig
2017-10-23 13:05 ` Robin Murphy
[not found] ` <037082e6-5abe-daf9-47aa-9586a4aead99-5wv7dgnIgG8@public.gmane.org>
2017-10-24 5:43 ` Kishon Vijay Abraham I
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=3599d3e2-d496-eac3-7179-2d1795fc059d@ti.com \
--to=kishon-l0cymroini0@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hch-jcswGhMUV9g@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=nsekhar-l0cyMroinI0@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=robin.murphy-5wv7dgnIgG8@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox