This patch series introduce support for _CCA object, which is currently used mainly by ARM64 platform to specify DMA coherency attribute for devices when booting with ACPI.
A copy of ACPIv6 can be found here: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
This patch also introduces a new APIS: 1. acpi_check_dma() as part of ACPI API. 2. device_dma_is_coherent() as part of unified device property API.
This simplifies the logic in device drivers to determine device coherency attribute regardless of booting with DT vs ACPI.
This has been tested on AMD-Seattle platform, which implements _CCA object as described in the AMD Opteron A1100 Series Processor ACPI Porting Guide:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_...
Changes from V4 (https://lkml.org/lkml/2015/5/15/669): * Patch1: - Move the arch_setup_dma_ops() call from acpi_create_platform_device() to acpi_bind_one() to support other bus types (per Rafael). - Rename acpi_device_flags.is_coherent to acpi_device_flags.coherent_dma. (per Rafael) - Refactor acpi_dma_is_supported() and acpi_dma_is_coherent() to acpi_check_dma() to simplify the new interface. - Only support _CCA=1 for now. See acpi_check_dma() (per Arnd and Catalin) * Patch2: - Add acked-by Catalin. * Patch3: - Use ACPI_COMPANION() instead of acpi_node(). - Remove has_acpi_companion() check since already done by acpi_node(). (per Will) * Remove the patch "Generic function for setting up PCI device DMA coherency" introduced in V4. (per Bjorn)
Changes from V3 (https://lkml.org/lkml/2015/5/7/1004): * Remove ARCH64_SUPPORT_ACPI_CCA_ZERO and just use CONFIG_ARM64. (per Catalin and Rafael) * Do not need to call arch_setup_dma_ops() for acpi_device->dev. (per Rafael) * [3/6] (New) We also need to call arch_setup_dma_ops() for pci devices and check the CCA of the host bridge. Similar logic exists for OF. So, I refactor of_pci_dma_configure() to the more generic version pci_dma_configure(), and add support for ACPI.
Changes from V2 (https://lkml.org/lkml/2015/5/5/510): * Reword ACPI_MUST_HAVE_CCA to ACPI_CCA_REQUIRED (per Rafael) * Reword ACPI_SUPPORT_CCA_ZERO to ARCH64_SUPPORT_ACPI_CCA_ZERO (per Rafael and Arnd) * Misc code styling clean up (per Rafael) * Only print missing _CCA warning message in debug mode. * Refactor logic in acpi_setup_device_dma() into if acpi_dma_is_supported() then call arch_setup_dma_ops(). * Do not allocate device dma_mask if !acpi_dma_is_supported() (per Arnd). * Re-use the dummy functions with the same signature.
Changes from V1 (https://lkml.org/lkml/2015/4/29/290): * Remove supports for 32-bit ARM since doesn't currently supporting ACPI (Per Catalin suggestions.) * Do not call arch_setup_dma_ops() and when _CCA is missing. (per Arnd suggestion) * Add CONFIG_ACPI_SUPPORT_CCA_ZERO kernel config flag to allow architectures to specify the behavior when _CCA=0. * Add dummy_dma_ops for ARM64 (per Catalin suggestions). * Fixed build error when ACPI is not configured by defining acpi_dma_is_coherent() for when CONFIG_ACPI is not set. * Introduce device_dma_is_coherent(). * Use device_dma_is_coherent in crypto/ccp and amd-xgbe driver.
Changes from RFC: (https://lkml.org/lkml/2015/4/1/389) * New logic for deriving and propagating coherent attribute from parent devices. (by Mark) * Introducing acpi_dma_is_coherent() API (Per Tom suggestion) * Introducing CONFIG_ACPI_MUST_HAVE_CCA kernel configuration. * Rebased to linux-4.1-rc1
Suravee Suthikulpanit (5): ACPI / scan: Parse _CCA and setup device coherency arm64 : Introduce support for ACPI _CCA object device property: Introduces device_dma_is_coherent() crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() amd-xgbe: Unify coherency checking logic with device_dma_is_coherent()
arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 92 +++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 3 + drivers/acpi/acpi_platform.c | 2 +- drivers/acpi/glue.c | 5 ++ drivers/acpi/scan.c | 35 ++++++++++++ drivers/base/property.c | 14 +++++ drivers/crypto/ccp/ccp-platform.c | 60 +------------------- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +-------- include/acpi/acpi_bus.h | 37 ++++++++++++- include/linux/acpi.h | 5 ++ include/linux/property.h | 2 + 13 files changed, 212 insertions(+), 89 deletions(-)
This patch implements support for ACPI _CCA object, which is introduced in ACPIv5.1, can be used for specifying device DMA coherency attribute.
The parsing logic traverses device namespace to parse coherency information, and stores it in acpi_device_flags. Then uses it to call arch_setup_dma_ops() when creating each device enumerated in DSDT during ACPI scan.
This patch also introduces acpi_dma_is_coherent(), which provides an interface for device drivers to check the coherency information similarly to the of_dma_is_coherent().
Signed-off-by: Mark Salter msalter@redhat.com Signed-off-by: Suravee Suthikulpanit Suravee.Suthikulpanit@amd.com --- drivers/acpi/Kconfig | 3 +++ drivers/acpi/acpi_platform.c | 2 +- drivers/acpi/glue.c | 5 +++++ drivers/acpi/scan.c | 35 +++++++++++++++++++++++++++++++++++ include/acpi/acpi_bus.h | 37 ++++++++++++++++++++++++++++++++++++- include/linux/acpi.h | 5 +++++ 6 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index ab2cbb5..212735f 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -54,6 +54,9 @@ config ACPI_GENERIC_GSI config ACPI_SYSTEM_POWER_STATES_SUPPORT bool
+config ACPI_CCA_REQUIRED + bool + config ACPI_SLEEP bool depends on SUSPEND || HIBERNATION diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 4bf7559..06a67d5 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -103,7 +103,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) pdevinfo.res = resources; pdevinfo.num_res = count; pdevinfo.fwnode = acpi_fwnode_handle(adev); - pdevinfo.dma_mask = DMA_BIT_MASK(32); + pdevinfo.dma_mask = acpi_check_dma(adev, NULL) ? DMA_BIT_MASK(32) : 0; pdev = platform_device_register_full(&pdevinfo); if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n", diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index 39c485b..b9657af 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -13,6 +13,7 @@ #include <linux/slab.h> #include <linux/rwsem.h> #include <linux/acpi.h> +#include <linux/dma-mapping.h>
#include "internal.h"
@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) struct list_head *physnode_list; unsigned int node_id; int retval = -EINVAL; + bool coherent;
if (has_acpi_companion(dev)) { if (acpi_dev) { @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) if (!has_acpi_companion(dev)) ACPI_COMPANION_SET(dev, acpi_dev);
+ if (acpi_check_dma(acpi_dev, &coherent)) + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); + acpi_physnode_link_name(physical_node_name, node_id); retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj, physical_node_name); diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 849b699..fdedb63 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -11,6 +11,7 @@ #include <linux/kthread.h> #include <linux/dmi.h> #include <linux/nls.h> +#include <linux/dma-mapping.h>
#include <asm/pgtable.h>
@@ -2137,6 +2138,39 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) kfree(pnp->unique_id); }
+static void acpi_init_coherency(struct acpi_device *adev) +{ + unsigned long long cca = 0; + acpi_status status; + struct acpi_device *parent = adev->parent; + + if (parent && parent->flags.cca_seen) { + /* + * From ACPI spec, OSPM will ignore _CCA if an ancestor + * already saw one. + */ + adev->flags.cca_seen = 1; + cca = parent->flags.coherent_dma; + } else { + status = acpi_evaluate_integer(adev->handle, "_CCA", + NULL, &cca); + if (ACPI_SUCCESS(status)) + adev->flags.cca_seen = 1; + else if (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED)) + /* + * If architecture does not specify that _CCA is + * required for DMA-able devices (e.g. x86), + * we default to _CCA=1. + */ + cca = 1; + else + acpi_handle_debug(adev->handle, + "ACPI device is missing _CCA.\n"); + } + + adev->flags.coherent_dma = cca; +} + void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, int type, unsigned long long sta) { @@ -2155,6 +2189,7 @@ void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, device->flags.visited = false; device_initialize(&device->dev); dev_set_uevent_suppress(&device->dev, true); + acpi_init_coherency(device); }
void acpi_device_add_finalize(struct acpi_device *device) diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index 8de4fa9..cbd1b57 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -208,7 +208,9 @@ struct acpi_device_flags { u32 visited:1; u32 hotplug_notify:1; u32 is_dock_station:1; - u32 reserved:23; + u32 coherent_dma:1; + u32 cca_seen:1; + u32 reserved:21; };
/* File System */ @@ -380,6 +382,39 @@ struct acpi_device { void (*remove)(struct acpi_device *); };
+static inline bool acpi_check_dma(struct acpi_device *adev, bool *coherent) +{ + bool ret = false; + + if (!adev) + return ret; + + /** + * Currently, we only support _CCA=1 (i.e. coherent_dma=1) + * This should be equivalent to specifyig dma-coherent for + * a device in OF. + * + * For the case when _CCA=0 (i.e. coherent_dma=0 && cca_seen=1), + * There are two cases: + * case 1. Do not support and disable DMA. + * case 2. Support but rely on arch-specific cache maintenance for + * non-coherence DMA operations. + * Currently, we implement case 1 above. + * + * For the case when _CCA is missing (i.e. cca_seen=0) and + * platform specifies ACPI_CCA_REQUIRED, we do not support DMA, + * and fallback to arch-specific default handling. + * + * See acpi_init_coherency() for more info. + */ + if (adev->flags.coherent_dma) { + ret = true; + if (coherent) + *coherent = adev->flags.coherent_dma; + } + return ret; +} + static inline bool is_acpi_node(struct fwnode_handle *fwnode) { return fwnode && fwnode->type == FWNODE_ACPI; diff --git a/include/linux/acpi.h b/include/linux/acpi.h index b10c4a6..30c81ac 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -583,6 +583,11 @@ static inline int acpi_device_modalias(struct device *dev, return -ENODEV; }
+static inline bool acpi_check_dma(struct acpi_device *adev, bool *coherent) +{ + return false; +} + #define ACPI_PTR(_ptr) (NULL)
#endif /* !CONFIG_ACPI */
On Wednesday, May 20, 2015 05:09:14 PM Suravee Suthikulpanit wrote:
This patch implements support for ACPI _CCA object, which is introduced in ACPIv5.1, can be used for specifying device DMA coherency attribute.
The parsing logic traverses device namespace to parse coherency information, and stores it in acpi_device_flags. Then uses it to call arch_setup_dma_ops() when creating each device enumerated in DSDT during ACPI scan.
This patch also introduces acpi_dma_is_coherent(), which provides an interface for device drivers to check the coherency information similarly to the of_dma_is_coherent().
Signed-off-by: Mark Salter msalter@redhat.com Signed-off-by: Suravee Suthikulpanit Suravee.Suthikulpanit@amd.com
drivers/acpi/Kconfig | 3 +++ drivers/acpi/acpi_platform.c | 2 +- drivers/acpi/glue.c | 5 +++++ drivers/acpi/scan.c | 35 +++++++++++++++++++++++++++++++++++ include/acpi/acpi_bus.h | 37 ++++++++++++++++++++++++++++++++++++- include/linux/acpi.h | 5 +++++ 6 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index ab2cbb5..212735f 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -54,6 +54,9 @@ config ACPI_GENERIC_GSI config ACPI_SYSTEM_POWER_STATES_SUPPORT bool +config ACPI_CCA_REQUIRED
- bool
config ACPI_SLEEP bool depends on SUSPEND || HIBERNATION diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 4bf7559..06a67d5 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -103,7 +103,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) pdevinfo.res = resources; pdevinfo.num_res = count; pdevinfo.fwnode = acpi_fwnode_handle(adev);
- pdevinfo.dma_mask = DMA_BIT_MASK(32);
- pdevinfo.dma_mask = acpi_check_dma(adev, NULL) ? DMA_BIT_MASK(32) : 0; pdev = platform_device_register_full(&pdevinfo); if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n",
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index 39c485b..b9657af 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -13,6 +13,7 @@ #include <linux/slab.h> #include <linux/rwsem.h> #include <linux/acpi.h> +#include <linux/dma-mapping.h> #include "internal.h" @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) struct list_head *physnode_list; unsigned int node_id; int retval = -EINVAL;
- bool coherent;
if (has_acpi_companion(dev)) { if (acpi_dev) { @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) if (!has_acpi_companion(dev)) ACPI_COMPANION_SET(dev, acpi_dev);
- if (acpi_check_dma(acpi_dev, &coherent))
arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
Well, so is this going to work for PCI too after all?
acpi_physnode_link_name(physical_node_name, node_id); retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj, physical_node_name);
Not sure if this went out earlier. So I am resending.
On 5/22/15 16:56, Rafael J. Wysocki wrote:
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 39c485b..b9657af 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -13,6 +13,7 @@ #include <linux/slab.h> #include <linux/rwsem.h> #include <linux/acpi.h> +#include <linux/dma-mapping.h>
#include "internal.h"
@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) struct list_head *physnode_list; unsigned int node_id; int retval = -EINVAL;
bool coherent;
if (has_acpi_companion(dev)) { if (acpi_dev) {
@@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) if (!has_acpi_companion(dev)) ACPI_COMPANION_SET(dev, acpi_dev);
- if (acpi_check_dma(acpi_dev, &coherent))
arch_setup_dma_ops(dev, 0, 0, NULL, coherent);Well, so is this going to work for PCI too after all?
No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA (patch 3/6 in V4) will be submitted separately. We are working on cleaning up and up-streaming the PCI ACPI support for ARM64.
Thanks,
Suravee
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
Not sure if this went out earlier. So I am resending.
On 5/22/15 16:56, Rafael J. Wysocki wrote:
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 39c485b..b9657af 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -13,6 +13,7 @@ #include <linux/slab.h> #include <linux/rwsem.h> #include <linux/acpi.h> +#include <linux/dma-mapping.h>
#include "internal.h"
@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) struct list_head *physnode_list; unsigned int node_id; int retval = -EINVAL;
bool coherent;
if (has_acpi_companion(dev)) { if (acpi_dev) {
@@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) if (!has_acpi_companion(dev)) ACPI_COMPANION_SET(dev, acpi_dev);
- if (acpi_check_dma(acpi_dev, &coherent))
arch_setup_dma_ops(dev, 0, 0, NULL, coherent);Well, so is this going to work for PCI too after all?
No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA (patch 3/6 in V4) will be submitted separately. We are working on cleaning up and up-streaming the PCI ACPI support for ARM64.
OK, but acpi_bind_one() is called for PCI devices too. Won't that be a problem?
On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
Not sure if this went out earlier. So I am resending.
On 5/22/15 16:56, Rafael J. Wysocki wrote:
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 39c485b..b9657af 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -13,6 +13,7 @@ #include <linux/slab.h> #include <linux/rwsem.h> #include <linux/acpi.h> +#include <linux/dma-mapping.h>
#include "internal.h"
@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) struct list_head *physnode_list; unsigned int node_id; int retval = -EINVAL;
bool coherent;
if (has_acpi_companion(dev)) { if (acpi_dev) {
@@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) if (!has_acpi_companion(dev)) ACPI_COMPANION_SET(dev, acpi_dev);
- if (acpi_check_dma(acpi_dev, &coherent))
arch_setup_dma_ops(dev, 0, 0, NULL, coherent);Well, so is this going to work for PCI too after all?
No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA (patch 3/6 in V4) will be submitted separately. We are working on cleaning up and up-streaming the PCI ACPI support for ARM64.
OK, but acpi_bind_one() is called for PCI devices too. Won't that be a problem?
In this case, we would be going through the following call path:
--> pci_device_add() |--> pci_dma_configure() ** 1 ** |--> device_add() |--> platform_notify() |--> acpi_platform_notify() |--> acpi_bind_one() ** 2 **
At (1), we would be calling arch_setup_dma_ops() with the PCI host bridge _CCA information. So, it should have already taken care of setting up device coherency here.
At (2), if there is no acpi_dev for endpoint devices (which I believe this is normally the case), it would return early and skip arch_setup_dma_ops().
At (2), if there is an acpi_dev, the coherent_dma flag should have already been setup by the acpi_init_device_object during ACPI scan. However, I am not certain about this case since I don't have the DSDT containing PCI endpoint devices to test with.
Thanks,
Suravee
On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
Not sure if this went out earlier. So I am resending.
On 5/22/15 16:56, Rafael J. Wysocki wrote:
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 39c485b..b9657af 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -13,6 +13,7 @@ #include <linux/slab.h> #include <linux/rwsem.h> #include <linux/acpi.h> +#include <linux/dma-mapping.h>
#include "internal.h"
@@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) struct list_head *physnode_list; unsigned int node_id; int retval = -EINVAL;
bool coherent;
if (has_acpi_companion(dev)) { if (acpi_dev) {
@@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) if (!has_acpi_companion(dev)) ACPI_COMPANION_SET(dev, acpi_dev);
- if (acpi_check_dma(acpi_dev, &coherent))
arch_setup_dma_ops(dev, 0, 0, NULL, coherent);Well, so is this going to work for PCI too after all?
No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA (patch 3/6 in V4) will be submitted separately. We are working on cleaning up and up-streaming the PCI ACPI support for ARM64.
OK, but acpi_bind_one() is called for PCI devices too. Won't that be a problem?
In this case, we would be going through the following call path:
--> pci_device_add() |--> pci_dma_configure() ** 1 ** |--> device_add() |--> platform_notify() |--> acpi_platform_notify() |--> acpi_bind_one() ** 2 **
At (1), we would be calling arch_setup_dma_ops() with the PCI host bridge _CCA information. So, it should have already taken care of setting up device coherency here.
At (2), if there is no acpi_dev for endpoint devices (which I believe this is normally the case), it would return early and skip arch_setup_dma_ops().
That's not correct. There may be ACPI companions for endpoint devices too.
At (2), if there is an acpi_dev, the coherent_dma flag should have already been setup by the acpi_init_device_object during ACPI scan.
That one sets the flag for the *ACPI* *companion* of the device, which I'm still thinking is pointless, isn't it?
However, I am not certain about this case since I don't have the DSDT containing PCI endpoint devices to test with.
Every x86 PC has them (as far as I can say), but in that case there's no _CCA and they are all coherent.
On 5/22/2015 8:25 PM, Rafael J. Wysocki wrote:
On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
Not sure if this went out earlier. So I am resending.
On 5/22/15 16:56, Rafael J. Wysocki wrote:
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c > index 39c485b..b9657af 100644 > --- a/drivers/acpi/glue.c > +++ b/drivers/acpi/glue.c > @@ -13,6 +13,7 @@ > #include <linux/slab.h> > #include <linux/rwsem.h> > #include <linux/acpi.h> > +#include <linux/dma-mapping.h> > > #include "internal.h" > > @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) > struct list_head *physnode_list; > unsigned int node_id; > int retval = -EINVAL; > + bool coherent; > > if (has_acpi_companion(dev)) { > if (acpi_dev) { > @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev) > if (!has_acpi_companion(dev)) > ACPI_COMPANION_SET(dev, acpi_dev); > > + if (acpi_check_dma(acpi_dev, &coherent)) > + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > +
Well, so is this going to work for PCI too after all?
No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA (patch 3/6 in V4) will be submitted separately. We are working on cleaning up and up-streaming the PCI ACPI support for ARM64.
OK, but acpi_bind_one() is called for PCI devices too. Won't that be a problem?
In this case, we would be going through the following call path:
--> pci_device_add() |--> pci_dma_configure() ** 1 ** |--> device_add() |--> platform_notify() |--> acpi_platform_notify() |--> acpi_bind_one() ** 2 **At (1), we would be calling arch_setup_dma_ops() with the PCI host bridge _CCA information. So, it should have already taken care of setting up device coherency here.
At (2), if there is no acpi_dev for endpoint devices (which I believe this is normally the case), it would return early and skip arch_setup_dma_ops().
That's not correct. There may be ACPI companions for endpoint devices too.
Ok. Duly noted :)
At (2), if there is an acpi_dev, the coherent_dma flag should have already been setup by the acpi_init_device_object during ACPI scan.
That one sets the flag for the *ACPI* *companion* of the device, which I'm still thinking is pointless, isn't it?
When you say pointless, are you referring to the part where we are end up calling arch_setup_dma_coherent() twice in this case? I am not quite following your point.
However, I am not certain about this case since I don't have the DSDT containing PCI endpoint devices to test with.
Every x86 PC has them (as far as I can say), but in that case there's no _CCA and they are all coherent.
Ok.
Thanks, Suravee
From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be specified for DMA-cabpable devices. Therefore, this patch specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
In addition, to handle the case when _CCA is missing, arm64 would assign dummy_dma_ops to disable DMA capability of the device.
Acked-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Mark Salter msalter@redhat.com Signed-off-by: Suravee Suthikulpanit Suravee.Suthikulpanit@amd.com --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-mapping.h | 18 ++++++- arch/arm64/mm/dma-mapping.c | 92 ++++++++++++++++++++++++++++++++++++ 3 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4269dba..95307b4 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1,5 +1,6 @@ config ARM64 def_bool y + select ACPI_CCA_REQUIRED if ACPI select ACPI_GENERIC_GSI if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h index 9437e3d..f0d6d0b 100644 --- a/arch/arm64/include/asm/dma-mapping.h +++ b/arch/arm64/include/asm/dma-mapping.h @@ -18,6 +18,7 @@
#ifdef __KERNEL__
+#include <linux/acpi.h> #include <linux/types.h> #include <linux/vmalloc.h>
@@ -28,13 +29,23 @@
#define DMA_ERROR_CODE (~(dma_addr_t)0) extern struct dma_map_ops *dma_ops; +extern struct dma_map_ops dummy_dma_ops;
static inline struct dma_map_ops *__generic_dma_ops(struct device *dev) { - if (unlikely(!dev) || !dev->archdata.dma_ops) + if (unlikely(!dev)) return dma_ops; - else + else if (dev->archdata.dma_ops) return dev->archdata.dma_ops; + else if (acpi_disabled) + return dma_ops; + + /* + * When ACPI is enabled, if arch_set_dma_ops is not called, + * we will disable device DMA capability by setting it + * to dummy_dma_ops. + */ + return &dummy_dma_ops; }
static inline struct dma_map_ops *get_dma_ops(struct device *dev) @@ -48,6 +59,9 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev) static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, struct iommu_ops *iommu, bool coherent) { + if (!acpi_disabled && !dev->archdata.dma_ops) + dev->archdata.dma_ops = dma_ops; + dev->archdata.dma_coherent = coherent; } #define arch_setup_dma_ops arch_setup_dma_ops diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index ef7d112..6e6d6ad 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -415,6 +415,98 @@ out: return -ENOMEM; }
+/******************************************** + * The following APIs are for dummy DMA ops * + ********************************************/ + +static void *__dummy_alloc(struct device *dev, size_t size, + dma_addr_t *dma_handle, gfp_t flags, + struct dma_attrs *attrs) +{ + return NULL; +} + +static void __dummy_free(struct device *dev, size_t size, + void *vaddr, dma_addr_t dma_handle, + struct dma_attrs *attrs) +{ +} + +static int __dummy_mmap(struct device *dev, + struct vm_area_struct *vma, + void *cpu_addr, dma_addr_t dma_addr, size_t size, + struct dma_attrs *attrs) +{ + return -ENXIO; +} + +static dma_addr_t __dummy_map_page(struct device *dev, struct page *page, + unsigned long offset, size_t size, + enum dma_data_direction dir, + struct dma_attrs *attrs) +{ + return DMA_ERROR_CODE; +} + +static void __dummy_unmap_page(struct device *dev, dma_addr_t dev_addr, + size_t size, enum dma_data_direction dir, + struct dma_attrs *attrs) +{ +} + +static int __dummy_map_sg(struct device *dev, struct scatterlist *sgl, + int nelems, enum dma_data_direction dir, + struct dma_attrs *attrs) +{ + return 0; +} + +static void __dummy_unmap_sg(struct device *dev, + struct scatterlist *sgl, int nelems, + enum dma_data_direction dir, + struct dma_attrs *attrs) +{ +} + +static void __dummy_sync_single(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg(struct device *dev, + struct scatterlist *sgl, int nelems, + enum dma_data_direction dir) +{ +} + +static int __dummy_mapping_error(struct device *hwdev, dma_addr_t dma_addr) +{ + return 1; +} + +static int __dummy_dma_supported(struct device *hwdev, u64 mask) +{ + return 0; +} + +struct dma_map_ops dummy_dma_ops = { + .alloc = __dummy_alloc, + .free = __dummy_free, + .mmap = __dummy_mmap, + .map_page = __dummy_map_page, + .unmap_page = __dummy_unmap_page, + .map_sg = __dummy_map_sg, + .unmap_sg = __dummy_unmap_sg, + .sync_single_for_cpu = __dummy_sync_single, + .sync_single_for_device = __dummy_sync_single, + .sync_sg_for_cpu = __dummy_sync_sg, + .sync_sg_for_device = __dummy_sync_sg, + .mapping_error = __dummy_mapping_error, + .dma_supported = __dummy_dma_supported, +}; +EXPORT_SYMBOL(dummy_dma_ops); + static int __init arm64_dma_init(void) { int ret;
On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote:
From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be specified for DMA-cabpable devices. Therefore, this patch specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
In addition, to handle the case when _CCA is missing, arm64 would assign dummy_dma_ops to disable DMA capability of the device.
Acked-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Mark Salter msalter@redhat.com Signed-off-by: Suravee Suthikulpanit Suravee.Suthikulpanit@amd.com
arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-mapping.h | 18 ++++++- arch/arm64/mm/dma-mapping.c | 92 ++++++++++++++++++++++++++++++++++++ 3 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4269dba..95307b4 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1,5 +1,6 @@ config ARM64 def_bool y
- select ACPI_CCA_REQUIRED if ACPI select ACPI_GENERIC_GSI if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h index 9437e3d..f0d6d0b 100644 --- a/arch/arm64/include/asm/dma-mapping.h +++ b/arch/arm64/include/asm/dma-mapping.h @@ -18,6 +18,7 @@ #ifdef __KERNEL__ +#include <linux/acpi.h> #include <linux/types.h> #include <linux/vmalloc.h>
^^^ This hunk causes build issues with a couple of drivers:
drivers/scsi/megaraid/megaraid_sas_fp.c:69:0: warning: "FALSE" redefined [enabled by default] #define FALSE 0 ^ In file included from include/acpi/acpi.h:58:0, from include/linux/acpi.h:37, from ./arch/arm64/include/asm/dma-mapping.h:21, from include/linux/dma-mapping.h:86, from ./arch/arm64/include/asm/pci.h:7, from include/linux/pci.h:1460, from drivers/scsi/megaraid/megaraid_sas_fp.c:37: include/acpi/actypes.h:433:0: note: this is the location of the previous definition #define FALSE (1 == 0) ^
In file included from include/acpi/acpi.h:58:0, from include/linux/acpi.h:37, from ./arch/arm64/include/asm/dma-mapping.h:21, from include/linux/dma-mapping.h:86, from include/scsi/scsi_cmnd.h:4, from drivers/scsi/ufs/ufshcd.h:60, from drivers/scsi/ufs/ufshcd.c:43: include/acpi/actypes.h:433:41: error: expected identifier before ‘(’ token #define FALSE (1 == 0) ^ drivers/scsi/ufs/unipro.h:203:2: note: in expansion of macro ‘FALSE’ FALSE = 0, ^
This happens because the ACPI definitions of TRUE and FALSE conflict with local definitions in megaraid and enum declaration in ufs.
@@ -28,13 +29,23 @@ #define DMA_ERROR_CODE (~(dma_addr_t)0) extern struct dma_map_ops *dma_ops; +extern struct dma_map_ops dummy_dma_ops; static inline struct dma_map_ops *__generic_dma_ops(struct device *dev) {
- if (unlikely(!dev) || !dev->archdata.dma_ops)
- if (unlikely(!dev)) return dma_ops;
- else
- else if (dev->archdata.dma_ops) return dev->archdata.dma_ops;
- else if (acpi_disabled)
return dma_ops;- /*
* When ACPI is enabled, if arch_set_dma_ops is not called,* we will disable device DMA capability by setting it* to dummy_dma_ops.*/- return &dummy_dma_ops;
} static inline struct dma_map_ops *get_dma_ops(struct device *dev) @@ -48,6 +59,9 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev) static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, struct iommu_ops *iommu, bool coherent) {
- if (!acpi_disabled && !dev->archdata.dma_ops)
dev->archdata.dma_ops = dma_ops;- dev->archdata.dma_coherent = coherent;
} #define arch_setup_dma_ops arch_setup_dma_ops diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c index ef7d112..6e6d6ad 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -415,6 +415,98 @@ out: return -ENOMEM; } +/********************************************
- The following APIs are for dummy DMA ops *
- ********************************************/
+static void *__dummy_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flags,struct dma_attrs *attrs)+{
- return NULL;
+}
+static void __dummy_free(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle,struct dma_attrs *attrs)+{ +}
+static int __dummy_mmap(struct device *dev,
struct vm_area_struct *vma,void *cpu_addr, dma_addr_t dma_addr, size_t size,struct dma_attrs *attrs)+{
- return -ENXIO;
+}
+static dma_addr_t __dummy_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size,enum dma_data_direction dir,struct dma_attrs *attrs)+{
- return DMA_ERROR_CODE;
+}
+static void __dummy_unmap_page(struct device *dev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir,struct dma_attrs *attrs)+{ +}
+static int __dummy_map_sg(struct device *dev, struct scatterlist *sgl,
int nelems, enum dma_data_direction dir,struct dma_attrs *attrs)+{
- return 0;
+}
+static void __dummy_unmap_sg(struct device *dev,
struct scatterlist *sgl, int nelems,enum dma_data_direction dir,struct dma_attrs *attrs)+{ +}
+static void __dummy_sync_single(struct device *dev,
dma_addr_t dev_addr, size_t size,enum dma_data_direction dir)+{ +}
+static void __dummy_sync_sg(struct device *dev,
struct scatterlist *sgl, int nelems,enum dma_data_direction dir)+{ +}
+static int __dummy_mapping_error(struct device *hwdev, dma_addr_t dma_addr) +{
- return 1;
+}
+static int __dummy_dma_supported(struct device *hwdev, u64 mask) +{
- return 0;
+}
+struct dma_map_ops dummy_dma_ops = {
- .alloc = __dummy_alloc,
- .free = __dummy_free,
- .mmap = __dummy_mmap,
- .map_page = __dummy_map_page,
- .unmap_page = __dummy_unmap_page,
- .map_sg = __dummy_map_sg,
- .unmap_sg = __dummy_unmap_sg,
- .sync_single_for_cpu = __dummy_sync_single,
- .sync_single_for_device = __dummy_sync_single,
- .sync_sg_for_cpu = __dummy_sync_sg,
- .sync_sg_for_device = __dummy_sync_sg,
- .mapping_error = __dummy_mapping_error,
- .dma_supported = __dummy_dma_supported,
+}; +EXPORT_SYMBOL(dummy_dma_ops);
static int __init arm64_dma_init(void) { int ret;
On 5/28/2015 9:38 PM, Mark Salter wrote:
On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote:
Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be specified for DMA-cabpable devices. Therefore, this patch specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
In addition, to handle the case when _CCA is missing, arm64 would assign dummy_dma_ops to disable DMA capability of the device.
Acked-by: Catalin Marinascatalin.marinas@arm.com Signed-off-by: Mark Saltermsalter@redhat.com Signed-off-by: Suravee SuthikulpanitSuravee.Suthikulpanit@amd.com
arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-mapping.h | 18 ++++++- arch/arm64/mm/dma-mapping.c | 92 ++++++++++++++++++++++++++++++++++++ 3 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4269dba..95307b4 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1,5 +1,6 @@ config ARM64 def_bool y
- select ACPI_CCA_REQUIRED if ACPI select ACPI_GENERIC_GSI if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h index 9437e3d..f0d6d0b 100644 --- a/arch/arm64/include/asm/dma-mapping.h +++ b/arch/arm64/include/asm/dma-mapping.h @@ -18,6 +18,7 @@
#ifdef __KERNEL__
+#include <linux/acpi.h> #include <linux/types.h> #include <linux/vmalloc.h>
^^^ This hunk causes build issues with a couple of drivers:
drivers/scsi/megaraid/megaraid_sas_fp.c:69:0: warning: "FALSE" redefined [enabled by default] #define FALSE 0 ^ In file included from include/acpi/acpi.h:58:0, from include/linux/acpi.h:37, from ./arch/arm64/include/asm/dma-mapping.h:21, from include/linux/dma-mapping.h:86, from ./arch/arm64/include/asm/pci.h:7, from include/linux/pci.h:1460, from drivers/scsi/megaraid/megaraid_sas_fp.c:37: include/acpi/actypes.h:433:0: note: this is the location of the previous definition #define FALSE (1 == 0) ^
In file included from include/acpi/acpi.h:58:0, from include/linux/acpi.h:37, from ./arch/arm64/include/asm/dma-mapping.h:21, from include/linux/dma-mapping.h:86, from include/scsi/scsi_cmnd.h:4, from drivers/scsi/ufs/ufshcd.h:60, from drivers/scsi/ufs/ufshcd.c:43: include/acpi/actypes.h:433:41: error: expected identifier before ‘(’ token #define FALSE (1 == 0) ^ drivers/scsi/ufs/unipro.h:203:2: note: in expansion of macro ‘FALSE’ FALSE = 0, ^
This happens because the ACPI definitions of TRUE and FALSE conflict with local definitions in megaraid and enum declaration in ufs.
Mark,
Thanks for pointing this out. Although, I would think that the megaraid_sas_fp.c should have had the #ifndef to check before defining the TRUE and FALSE as following.
#ifndef TRUE #define TRUE 1 #endif #ifndef FALSE #define FALSE 0 #endif
This seems to be what other drivers are also doing. If this is okay, I can send out a fix-up patch for the megaraid driver.
Thanks,
Suravee
On Wed, 2015-06-03 at 09:37 -0500, Suravee Suthikulanit wrote:
On 5/28/2015 9:38 PM, Mark Salter wrote:
On Wed, 2015-05-20 at 17:09 -0500, Suravee Suthikulpanit wrote:
Fromhttp://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf, section 6.2.17 _CCA states that ARM platforms require ACPI _CCA object to be specified for DMA-cabpable devices. Therefore, this patch specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
In addition, to handle the case when _CCA is missing, arm64 would assign dummy_dma_ops to disable DMA capability of the device.
Acked-by: Catalin Marinascatalin.marinas@arm.com Signed-off-by: Mark Saltermsalter@redhat.com Signed-off-by: Suravee SuthikulpanitSuravee.Suthikulpanit@amd.com
arch/arm64/Kconfig | 1 + arch/arm64/include/asm/dma-mapping.h | 18 ++++++- arch/arm64/mm/dma-mapping.c | 92 ++++++++++++++++++++++++++++++++++++ 3 files changed, 109 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4269dba..95307b4 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1,5 +1,6 @@ config ARM64 def_bool y
- select ACPI_CCA_REQUIRED if ACPI select ACPI_GENERIC_GSI if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h index 9437e3d..f0d6d0b 100644 --- a/arch/arm64/include/asm/dma-mapping.h +++ b/arch/arm64/include/asm/dma-mapping.h @@ -18,6 +18,7 @@
#ifdef __KERNEL__
+#include <linux/acpi.h> #include <linux/types.h> #include <linux/vmalloc.h>
^^^ This hunk causes build issues with a couple of drivers:
drivers/scsi/megaraid/megaraid_sas_fp.c:69:0: warning: "FALSE" redefined [enabled by default] #define FALSE 0 ^ In file included from include/acpi/acpi.h:58:0, from include/linux/acpi.h:37, from ./arch/arm64/include/asm/dma-mapping.h:21, from include/linux/dma-mapping.h:86, from ./arch/arm64/include/asm/pci.h:7, from include/linux/pci.h:1460, from drivers/scsi/megaraid/megaraid_sas_fp.c:37: include/acpi/actypes.h:433:0: note: this is the location of the previous definition #define FALSE (1 == 0) ^
In file included from include/acpi/acpi.h:58:0, from include/linux/acpi.h:37, from ./arch/arm64/include/asm/dma-mapping.h:21, from include/linux/dma-mapping.h:86, from include/scsi/scsi_cmnd.h:4, from drivers/scsi/ufs/ufshcd.h:60, from drivers/scsi/ufs/ufshcd.c:43: include/acpi/actypes.h:433:41: error: expected identifier before ‘(’ token #define FALSE (1 == 0) ^ drivers/scsi/ufs/unipro.h:203:2: note: in expansion of macro ‘FALSE’ FALSE = 0, ^
This happens because the ACPI definitions of TRUE and FALSE conflict with local definitions in megaraid and enum declaration in ufs.
Mark,
Thanks for pointing this out. Although, I would think that the megaraid_sas_fp.c should have had the #ifndef to check before defining the TRUE and FALSE as following.
#ifndef TRUE #define TRUE 1 #endif #ifndef FALSE #define FALSE 0 #endif
This seems to be what other drivers are also doing. If this is okay, I can send out a fix-up patch for the megaraid driver.
Yeah, or #undef them if defined so megaraid defines them as desired. And #undef if defined would work for unipro.h as well.
Currently, device drivers, which support both OF and ACPI, need to call two separate APIs, of_dma_is_coherent() and acpi_dma_is_coherent()) to determine device coherency attribute.
This patch simplifies this process by introducing a new device property API, device_dma_is_coherent(), which calls the appropriate interface based on the booting architecture.
Signed-off-by: Suravee Suthikulpanit Suravee.Suthikulpanit@amd.com --- drivers/base/property.c | 14 ++++++++++++++ include/linux/property.h | 2 ++ 2 files changed, 16 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c index 1d0b116..e645852 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -14,6 +14,7 @@ #include <linux/export.h> #include <linux/kernel.h> #include <linux/of.h> +#include <linux/of_address.h> #include <linux/property.h>
/** @@ -519,3 +520,16 @@ unsigned int device_get_child_node_count(struct device *dev) return count; } EXPORT_SYMBOL_GPL(device_get_child_node_count); + +bool device_dma_is_coherent(struct device *dev) +{ + bool coherent = false; + + if (IS_ENABLED(CONFIG_OF) && dev->of_node) + coherent = of_dma_is_coherent(dev->of_node); + else + acpi_check_dma(ACPI_COMPANION(dev), &coherent); + + return coherent; +} +EXPORT_SYMBOL_GPL(device_dma_is_coherent); diff --git a/include/linux/property.h b/include/linux/property.h index de8bdf4..76ebde9 100644 --- a/include/linux/property.h +++ b/include/linux/property.h @@ -164,4 +164,6 @@ struct property_set {
void device_add_property_set(struct device *dev, struct property_set *pset);
+bool device_dma_is_coherent(struct device *dev); + #endif /* _LINUX_PROPERTY_H_ */
Currently, the driver has separate logic to determine device coherency for DT vs ACPI. This patch simplifies the code with a call to device_dma_is_coherent().
Signed-off-by: Tom Lendacky thomas.lendacky@amd.com Signed-off-by: Suravee Suthikulpanit Suravee.Suthikulpanit@amd.com --- drivers/crypto/ccp/ccp-platform.c | 60 +-------------------------------------- 1 file changed, 1 insertion(+), 59 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-platform.c b/drivers/crypto/ccp/ccp-platform.c index b1c20b2..e446781 100644 --- a/drivers/crypto/ccp/ccp-platform.c +++ b/drivers/crypto/ccp/ccp-platform.c @@ -90,58 +90,6 @@ static struct resource *ccp_find_mmio_area(struct ccp_device *ccp) return NULL; }
-#ifdef CONFIG_ACPI -static int ccp_acpi_support(struct ccp_device *ccp) -{ - struct ccp_platform *ccp_platform = ccp->dev_specific; - struct acpi_device *adev = ACPI_COMPANION(ccp->dev); - acpi_handle handle; - acpi_status status; - unsigned long long data; - int cca; - - /* Retrieve the device cache coherency value */ - handle = adev->handle; - do { - status = acpi_evaluate_integer(handle, "_CCA", NULL, &data); - if (!ACPI_FAILURE(status)) { - cca = data; - break; - } - } while (!ACPI_FAILURE(status)); - - if (ACPI_FAILURE(status)) { - dev_err(ccp->dev, "error obtaining acpi coherency value\n"); - return -EINVAL; - } - - ccp_platform->coherent = !!cca; - - return 0; -} -#else /* CONFIG_ACPI */ -static int ccp_acpi_support(struct ccp_device *ccp) -{ - return -EINVAL; -} -#endif - -#ifdef CONFIG_OF -static int ccp_of_support(struct ccp_device *ccp) -{ - struct ccp_platform *ccp_platform = ccp->dev_specific; - - ccp_platform->coherent = of_dma_is_coherent(ccp->dev->of_node); - - return 0; -} -#else -static int ccp_of_support(struct ccp_device *ccp) -{ - return -EINVAL; -} -#endif - static int ccp_platform_probe(struct platform_device *pdev) { struct ccp_device *ccp; @@ -182,13 +130,7 @@ static int ccp_platform_probe(struct platform_device *pdev) goto e_err; }
- if (ccp_platform->use_acpi) - ret = ccp_acpi_support(ccp); - else - ret = ccp_of_support(ccp); - if (ret) - goto e_err; - + ccp_platform->coherent = device_dma_is_coherent(ccp->dev); if (ccp_platform->coherent) ccp->axcache = CACHE_WB_NO_ALLOC; else
Currently, amd-xgbe driver has separate logic to determine device coherency for DT vs. ACPI. This patch simplifies the code with a call to device_dma_is_coherent().
Signed-off-by: Tom Lendacky thomas.lendacky@amd.com Signed-off-by: Suravee Suthikulpanit Suravee.Suthikulpanit@amd.com --- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c b/drivers/net/ethernet/amd/xgbe/xgbe-main.c index 7149053..6d2c702 100644 --- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c +++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c @@ -168,13 +168,8 @@ static void xgbe_init_all_fptrs(struct xgbe_prv_data *pdata) #ifdef CONFIG_ACPI static int xgbe_acpi_support(struct xgbe_prv_data *pdata) { - struct acpi_device *adev = pdata->adev; struct device *dev = pdata->dev; u32 property; - acpi_handle handle; - acpi_status status; - unsigned long long data; - int cca; int ret;
/* Obtain the system clock setting */ @@ -195,24 +190,6 @@ static int xgbe_acpi_support(struct xgbe_prv_data *pdata) } pdata->ptpclk_rate = property;
- /* Retrieve the device cache coherency value */ - handle = adev->handle; - do { - status = acpi_evaluate_integer(handle, "_CCA", NULL, &data); - if (!ACPI_FAILURE(status)) { - cca = data; - break; - } - - status = acpi_get_parent(handle, &handle); - } while (!ACPI_FAILURE(status)); - - if (ACPI_FAILURE(status)) { - dev_err(dev, "error obtaining acpi coherency value\n"); - return -EINVAL; - } - pdata->coherent = !!cca; - return 0; } #else /* CONFIG_ACPI */ @@ -243,9 +220,6 @@ static int xgbe_of_support(struct xgbe_prv_data *pdata) } pdata->ptpclk_rate = clk_get_rate(pdata->ptpclk);
- /* Retrieve the device cache coherency value */ - pdata->coherent = of_dma_is_coherent(dev->of_node); - return 0; } #else /* CONFIG_OF */ @@ -364,6 +338,7 @@ static int xgbe_probe(struct platform_device *pdev) goto err_io;
/* Set the DMA coherency values */ + pdata->coherent = device_dma_is_coherent(pdata->dev); if (pdata->coherent) { pdata->axdomain = XGBE_DMA_OS_AXDOMAIN; pdata->arcache = XGBE_DMA_OS_ARCACHE;
-
Mark Salter -
Rafael J. Wysocki -
Suravee Suthikulanit -
Suravee Suthikulpanit