diff mbox

arm64/pci: fix dma coherency inheritance for PCI devices

Message ID 1411141886-11310-1-git-send-email-msalter@redhat.com
State New
Headers show

Commit Message

Mark Salter Sept. 19, 2014, 3:51 p.m. UTC
The default dma_ops for devices on arm64 systems are noncoherent in
nature and rely upon special operations and bounce buffers to
perform a device DMA operation to/from memory. Some drivers rely
upon coherent operations involving suitably capable hardware. In
this case, a "dma-coherent" property will exist on the corresponding
Device Tree node for the bridge device, or one of its ancestors.
This patch adds support for applying a DMA coherent dma_ops for
PCI devices in the case of such a property.

Signed-off-by: Jon Masters <jcm@redhat.com>
[added search for device with of_node]
Signed-off-by: Mark Salter <msalter@redhat.com>
---
 arch/arm64/mm/dma-mapping.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

Comments

Will Deacon Sept. 19, 2014, 4:28 p.m. UTC | #1
On Fri, Sep 19, 2014 at 04:51:26PM +0100, Mark Salter wrote:
> The default dma_ops for devices on arm64 systems are noncoherent in
> nature and rely upon special operations and bounce buffers to
> perform a device DMA operation to/from memory. Some drivers rely
> upon coherent operations involving suitably capable hardware. In
> this case, a "dma-coherent" property will exist on the corresponding
> Device Tree node for the bridge device, or one of its ancestors.
> This patch adds support for applying a DMA coherent dma_ops for
> PCI devices in the case of such a property.
> 
> Signed-off-by: Jon Masters <jcm@redhat.com>
> [added search for device with of_node]
> Signed-off-by: Mark Salter <msalter@redhat.com>
> ---
>  arch/arm64/mm/dma-mapping.c | 21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 4164c5a..0e26bd7 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -23,10 +23,12 @@
>  #include <linux/dma-mapping.h>
>  #include <linux/dma-contiguous.h>
>  #include <linux/of.h>
> +#include <linux/of_address.h>
>  #include <linux/platform_device.h>
>  #include <linux/vmalloc.h>
>  #include <linux/swiotlb.h>
>  #include <linux/amba/bus.h>
> +#include <linux/pci.h>
>  
>  #include <asm/cacheflush.h>
>  
> @@ -316,8 +318,18 @@ static int dma_bus_notifier(struct notifier_block *nb,
>  	if (event != BUS_NOTIFY_ADD_DEVICE)
>  		return NOTIFY_DONE;
>  
> -	if (of_property_read_bool(dev->of_node, "dma-coherent"))
> -		set_dma_ops(dev, &coherent_swiotlb_dma_ops);
> +	/*
> +	 * Some devices won't have an of_node but a bus controller/bridge will.
> +	 * Search up the device chain until we find an of_node to check.
> +	 */
> +	while (dev) {
> +		if (dev->of_node) {
> +			if (of_dma_is_coherent(dev->of_node))
> +				set_dma_ops(_dev, &coherent_swiotlb_dma_ops);
> +			break;
> +		}
> +		dev = dev->parent;
> +	}

Hmm, how does this interact with of_dma_configure? I don't think the
dma-coherent property is inherited there, so I'm uneasy about doing this for
buses other than PCI (i.e. the platform bus).

In other words, we should move to using of_dma_configure for the platform
and amba buses, and have a separate notifier for the PCI bus. Is it likely
that people will have a mixture of coherent and non-coherent devices behind
the same host controller?

Will

>  	return NOTIFY_OK;
>  }
> @@ -330,6 +342,10 @@ static struct notifier_block amba_bus_nb = {
>  	.notifier_call = dma_bus_notifier,
>  };
>  
> +static struct notifier_block pci_bus_nb = {
> +	.notifier_call = dma_bus_notifier,
> +};
> +
>  extern int swiotlb_late_init_with_default_size(size_t default_size);
>  
>  static int __init swiotlb_late_init(void)
> @@ -341,6 +357,7 @@ static int __init swiotlb_late_init(void)
>  	 */
>  	bus_register_notifier(&platform_bus_type, &platform_bus_nb);
>  	bus_register_notifier(&amba_bustype, &amba_bus_nb);
> +	bus_register_notifier(&pci_bus_type, &pci_bus_nb);
>  
>  	dma_ops = &noncoherent_swiotlb_dma_ops;
>  
> -- 
> 1.9.3
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jon Masters Sept. 19, 2014, 4:32 p.m. UTC | #2
On 09/19/2014 12:28 PM, Will Deacon wrote:
> On Fri, Sep 19, 2014 at 04:51:26PM +0100, Mark Salter wrote:
>> The default dma_ops for devices on arm64 systems are noncoherent in
>> nature and rely upon special operations and bounce buffers to
>> perform a device DMA operation to/from memory. Some drivers rely
>> upon coherent operations involving suitably capable hardware. In
>> this case, a "dma-coherent" property will exist on the corresponding
>> Device Tree node for the bridge device, or one of its ancestors.
>> This patch adds support for applying a DMA coherent dma_ops for
>> PCI devices in the case of such a property.
>>
>> Signed-off-by: Jon Masters <jcm@redhat.com>
>> [added search for device with of_node]
>> Signed-off-by: Mark Salter <msalter@redhat.com>
>> ---
>>  arch/arm64/mm/dma-mapping.c | 21 +++++++++++++++++++--
>>  1 file changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 4164c5a..0e26bd7 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -23,10 +23,12 @@
>>  #include <linux/dma-mapping.h>
>>  #include <linux/dma-contiguous.h>
>>  #include <linux/of.h>
>> +#include <linux/of_address.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/vmalloc.h>
>>  #include <linux/swiotlb.h>
>>  #include <linux/amba/bus.h>
>> +#include <linux/pci.h>
>>  
>>  #include <asm/cacheflush.h>
>>  
>> @@ -316,8 +318,18 @@ static int dma_bus_notifier(struct notifier_block *nb,
>>  	if (event != BUS_NOTIFY_ADD_DEVICE)
>>  		return NOTIFY_DONE;
>>  
>> -	if (of_property_read_bool(dev->of_node, "dma-coherent"))
>> -		set_dma_ops(dev, &coherent_swiotlb_dma_ops);
>> +	/*
>> +	 * Some devices won't have an of_node but a bus controller/bridge will.
>> +	 * Search up the device chain until we find an of_node to check.
>> +	 */
>> +	while (dev) {
>> +		if (dev->of_node) {
>> +			if (of_dma_is_coherent(dev->of_node))
>> +				set_dma_ops(_dev, &coherent_swiotlb_dma_ops);
>> +			break;
>> +		}
>> +		dev = dev->parent;
>> +	}
> 
> Hmm, how does this interact with of_dma_configure? I don't think the
> dma-coherent property is inherited there, so I'm uneasy about doing this for
> buses other than PCI (i.e. the platform bus).
> 
> In other words, we should move to using of_dma_configure for the platform
> and amba buses, and have a separate notifier for the PCI bus. Is it likely
> that people will have a mixture of coherent and non-coherent devices behind
> the same host controller?

Right. My original internal patch had a separate method for the PCI bus
rather than rolling these back into one...but I suggested to Mark that I
thought Catalin and you wanted this rolled back into one. If you'd
rather there be two, well that's really easy as we know that works.

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Mark Salter Sept. 19, 2014, 4:42 p.m. UTC | #3
On Fri, 2014-09-19 at 17:28 +0100, Will Deacon wrote:
> On Fri, Sep 19, 2014 at 04:51:26PM +0100, Mark Salter wrote:
> > The default dma_ops for devices on arm64 systems are noncoherent in
> > nature and rely upon special operations and bounce buffers to
> > perform a device DMA operation to/from memory. Some drivers rely
> > upon coherent operations involving suitably capable hardware. In
> > this case, a "dma-coherent" property will exist on the corresponding
> > Device Tree node for the bridge device, or one of its ancestors.
> > This patch adds support for applying a DMA coherent dma_ops for
> > PCI devices in the case of such a property.
> > 
> > Signed-off-by: Jon Masters <jcm@redhat.com>
> > [added search for device with of_node]
> > Signed-off-by: Mark Salter <msalter@redhat.com>
> > ---
> >  arch/arm64/mm/dma-mapping.c | 21 +++++++++++++++++++--
> >  1 file changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> > index 4164c5a..0e26bd7 100644
> > --- a/arch/arm64/mm/dma-mapping.c
> > +++ b/arch/arm64/mm/dma-mapping.c
> > @@ -23,10 +23,12 @@
> >  #include <linux/dma-mapping.h>
> >  #include <linux/dma-contiguous.h>
> >  #include <linux/of.h>
> > +#include <linux/of_address.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/vmalloc.h>
> >  #include <linux/swiotlb.h>
> >  #include <linux/amba/bus.h>
> > +#include <linux/pci.h>
> >  
> >  #include <asm/cacheflush.h>
> >  
> > @@ -316,8 +318,18 @@ static int dma_bus_notifier(struct notifier_block *nb,
> >  	if (event != BUS_NOTIFY_ADD_DEVICE)
> >  		return NOTIFY_DONE;
> >  
> > -	if (of_property_read_bool(dev->of_node, "dma-coherent"))
> > -		set_dma_ops(dev, &coherent_swiotlb_dma_ops);
> > +	/*
> > +	 * Some devices won't have an of_node but a bus controller/bridge will.
> > +	 * Search up the device chain until we find an of_node to check.
> > +	 */
> > +	while (dev) {
> > +		if (dev->of_node) {
> > +			if (of_dma_is_coherent(dev->of_node))
> > +				set_dma_ops(_dev, &coherent_swiotlb_dma_ops);
> > +			break;
> > +		}
> > +		dev = dev->parent;
> > +	}
> 
> Hmm, how does this interact with of_dma_configure? I don't think the
> dma-coherent property is inherited there, so I'm uneasy about doing this for
> buses other than PCI (i.e. the platform bus).

of_dma_configure() only gets called for platform bus and it
uses of_dma_is_coherent() which searches device ancestors for
dma-coherent property. But it uses set_arch_dma_coherent_ops()
which is a no-op on arm64 now. Catalin mentions this in another
thread: https://lkml.org/lkml/2014/9/15/363

So maybe we should fix set_arch_dma_coherent_ops() and drop
platform bus from the notifier handler.

> 
> In other words, we should move to using of_dma_configure for the platform
> and amba buses, and have a separate notifier for the PCI bus. Is it likely
> that people will have a mixture of coherent and non-coherent devices behind
> the same host controller?
> 
> Will
> 
> >  	return NOTIFY_OK;
> >  }
> > @@ -330,6 +342,10 @@ static struct notifier_block amba_bus_nb = {
> >  	.notifier_call = dma_bus_notifier,
> >  };
> >  
> > +static struct notifier_block pci_bus_nb = {
> > +	.notifier_call = dma_bus_notifier,
> > +};
> > +
> >  extern int swiotlb_late_init_with_default_size(size_t default_size);
> >  
> >  static int __init swiotlb_late_init(void)
> > @@ -341,6 +357,7 @@ static int __init swiotlb_late_init(void)
> >  	 */
> >  	bus_register_notifier(&platform_bus_type, &platform_bus_nb);
> >  	bus_register_notifier(&amba_bustype, &amba_bus_nb);
> > +	bus_register_notifier(&pci_bus_type, &pci_bus_nb);
> >  
> >  	dma_ops = &noncoherent_swiotlb_dma_ops;
> >  
> > -- 
> > 1.9.3
> > 
> > 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Catalin Marinas Sept. 22, 2014, 10:23 a.m. UTC | #4
On Fri, Sep 19, 2014 at 04:51:26PM +0100, Mark Salter wrote:
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 4164c5a..0e26bd7 100644
[...]
> @@ -316,8 +318,18 @@ static int dma_bus_notifier(struct notifier_block *nb,
>  	if (event != BUS_NOTIFY_ADD_DEVICE)
>  		return NOTIFY_DONE;
>  
> -	if (of_property_read_bool(dev->of_node, "dma-coherent"))
> -		set_dma_ops(dev, &coherent_swiotlb_dma_ops);
> +	/*
> +	 * Some devices won't have an of_node but a bus controller/bridge will.
> +	 * Search up the device chain until we find an of_node to check.
> +	 */
> +	while (dev) {
> +		if (dev->of_node) {
> +			if (of_dma_is_coherent(dev->of_node))
> +				set_dma_ops(_dev, &coherent_swiotlb_dma_ops);
> +			break;
> +		}
> +		dev = dev->parent;
> +	}
>  
>  	return NOTIFY_OK;
>  }

For AMBA (with an additional patch) and platform devices, we can do the
same as ARM and rely on set_arch_dma_coherent_ops(), so most of the
notifier code removed. So we leave the above notifier for PCI only.

>  static int __init swiotlb_late_init(void)
> @@ -341,6 +357,7 @@ static int __init swiotlb_late_init(void)
>  	 */
>  	bus_register_notifier(&platform_bus_type, &platform_bus_nb);
>  	bus_register_notifier(&amba_bustype, &amba_bus_nb);
> +	bus_register_notifier(&pci_bus_type, &pci_bus_nb);

Does this compile when CONFIG_PCI is disabled?
Mark Salter Sept. 22, 2014, 2:30 p.m. UTC | #5
On Mon, 2014-09-22 at 11:23 +0100, Catalin Marinas wrote:
> >  static int __init swiotlb_late_init(void)
> > @@ -341,6 +357,7 @@ static int __init swiotlb_late_init(void)
> >        */
> >       bus_register_notifier(&platform_bus_type, &platform_bus_nb);
> >       bus_register_notifier(&amba_bustype, &amba_bus_nb);
> > +     bus_register_notifier(&pci_bus_type, &pci_bus_nb);
> 
> Does this compile when CONFIG_PCI is disabled?

No. Doh!



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
diff mbox

Patch

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4164c5a..0e26bd7 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -23,10 +23,12 @@ 
 #include <linux/dma-mapping.h>
 #include <linux/dma-contiguous.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/platform_device.h>
 #include <linux/vmalloc.h>
 #include <linux/swiotlb.h>
 #include <linux/amba/bus.h>
+#include <linux/pci.h>
 
 #include <asm/cacheflush.h>
 
@@ -316,8 +318,18 @@  static int dma_bus_notifier(struct notifier_block *nb,
 	if (event != BUS_NOTIFY_ADD_DEVICE)
 		return NOTIFY_DONE;
 
-	if (of_property_read_bool(dev->of_node, "dma-coherent"))
-		set_dma_ops(dev, &coherent_swiotlb_dma_ops);
+	/*
+	 * Some devices won't have an of_node but a bus controller/bridge will.
+	 * Search up the device chain until we find an of_node to check.
+	 */
+	while (dev) {
+		if (dev->of_node) {
+			if (of_dma_is_coherent(dev->of_node))
+				set_dma_ops(_dev, &coherent_swiotlb_dma_ops);
+			break;
+		}
+		dev = dev->parent;
+	}
 
 	return NOTIFY_OK;
 }
@@ -330,6 +342,10 @@  static struct notifier_block amba_bus_nb = {
 	.notifier_call = dma_bus_notifier,
 };
 
+static struct notifier_block pci_bus_nb = {
+	.notifier_call = dma_bus_notifier,
+};
+
 extern int swiotlb_late_init_with_default_size(size_t default_size);
 
 static int __init swiotlb_late_init(void)
@@ -341,6 +357,7 @@  static int __init swiotlb_late_init(void)
 	 */
 	bus_register_notifier(&platform_bus_type, &platform_bus_nb);
 	bus_register_notifier(&amba_bustype, &amba_bus_nb);
+	bus_register_notifier(&pci_bus_type, &pci_bus_nb);
 
 	dma_ops = &noncoherent_swiotlb_dma_ops;