* [V2 PATCH 0/5] Introduce ACPI _CCA support and device_dma_is_coherent API @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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 2 new APIS: 1. acpi_dma_is_coherent() 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_Guide.pdf 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 | 2 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 104 ++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 6 ++ drivers/acpi/acpi_platform.c | 4 +- drivers/acpi/scan.c | 62 ++++++++++++++++++ drivers/base/property.c | 12 ++++ drivers/crypto/ccp/ccp-platform.c | 60 +---------------- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +------- include/acpi/acpi_bus.h | 11 +++- include/linux/acpi.h | 5 ++ include/linux/property.h | 2 + 12 files changed, 224 insertions(+), 89 deletions(-) -- 2.1.0 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 0/5] Introduce ACPI _CCA support and device_dma_is_coherent API @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: linux-arm-kernel 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 2 new APIS: 1. acpi_dma_is_coherent() 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_Guide.pdf 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 | 2 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 104 ++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 6 ++ drivers/acpi/acpi_platform.c | 4 +- drivers/acpi/scan.c | 62 ++++++++++++++++++ drivers/base/property.c | 12 ++++ drivers/crypto/ccp/ccp-platform.c | 60 +---------------- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +------- include/acpi/acpi_bus.h | 11 +++- include/linux/acpi.h | 5 ++ include/linux/property.h | 2 + 12 files changed, 224 insertions(+), 89 deletions(-) -- 2.1.0 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 0/5] Introduce ACPI _CCA support and device_dma_is_coherent API @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Suravee Suthikulpanit 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 2 new APIS: 1. acpi_dma_is_coherent() 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_Guide.pdf 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 | 2 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 104 ++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 6 ++ drivers/acpi/acpi_platform.c | 4 +- drivers/acpi/scan.c | 62 ++++++++++++++++++ drivers/base/property.c | 12 ++++ drivers/crypto/ccp/ccp-platform.c | 60 +---------------- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +------- include/acpi/acpi_bus.h | 11 +++- include/linux/acpi.h | 5 ++ include/linux/property.h | 2 + 12 files changed, 224 insertions(+), 89 deletions(-) -- 2.1.0 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 0/5] Introduce ACPI _CCA support and device_dma_is_coherent API @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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 2 new APIS: 1. acpi_dma_is_coherent() 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_Guide.pdf 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 | 2 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 104 ++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 6 ++ drivers/acpi/acpi_platform.c | 4 +- drivers/acpi/scan.c | 62 ++++++++++++++++++ drivers/base/property.c | 12 ++++ drivers/crypto/ccp/ccp-platform.c | 60 +---------------- drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +------- include/acpi/acpi_bus.h | 11 +++- include/linux/acpi.h | 5 ++ include/linux/property.h | 2 + 12 files changed, 224 insertions(+), 89 deletions(-) -- 2.1.0 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-05 15:12 ` Suravee Suthikulpanit (?) (?) @ 2015-05-05 15:12 ` Suravee Suthikulpanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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> --- NOTE: * Since there seem to be conflict opinions regarding how architecture should handle _CCA=0. So, I am proposing the CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by for each architecture to define behavior of the ACPI scanning code when _CCA=0. Let me know if this is acceptable. drivers/acpi/Kconfig | 6 +++++ drivers/acpi/acpi_platform.c | 4 ++- drivers/acpi/scan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ include/acpi/acpi_bus.h | 11 +++++++- include/linux/acpi.h | 5 ++++ 5 files changed, 86 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index ab2cbb5..dd386e9 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI config ACPI_SYSTEM_POWER_STATES_SUPPORT bool +config ACPI_MUST_HAVE_CCA + bool + +config ACPI_SUPPORT_CCA_ZERO + 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..a6feca4 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n", PTR_ERR(pdev)); - else + else { + acpi_setup_device_dma(adev, &pdev->dev); dev_dbg(&adev->dev, "created platform device %s\n", dev_name(&pdev->dev)); + } kfree(resources); return pdev; diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) kfree(pnp->unique_id); } +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) +{ + int coherent = acpi_dma_is_coherent(adev); + + /** + * Currently, we only support DMA for devices that _CCA=1 + * since this seems to be the case on most ACPI platforms. + * + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), + * we would rely on arch-specific cache maintenance for + * non-coherence DMA operations if architecture enables + * CONFIG_ACPI_SUPPORT_CCA_ZERO. + * + * For the case when _CCA is missing but platform requires it + * (i.e. is_coherent=0 && cca_seen=0), we do not call + * arch_setup_dma_ops() and fallback to arch-specific default + * handling. + */ + if (adev->flags.cca_seen) { + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) + return; + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); + } +} + +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 = acpi_dma_is_coherent(parent); + } 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_MUST_HAVE_CCA)) { + /* + * If architecture does not specify that _CCA is + * required for DMA-able devices (e.g. x86), + * we default to _CCA=1. + */ + cca = 1; + } else { + dev_err(&adev->dev, FW_BUG + "DMA is not setup due to missing _CCA.\n"); + } + } + + adev->flags.is_coherent = cca; + acpi_setup_device_dma(adev, &adev->dev); +} + void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, int type, unsigned long long sta) { @@ -2155,6 +2216,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..b804183 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 is_coherent:1; + u32 cca_seen:1; + u32 reserved:21; }; /* File System */ @@ -380,6 +382,13 @@ struct acpi_device { void (*remove)(struct acpi_device *); }; +static inline bool acpi_dma_is_coherent(struct acpi_device *adev) +{ + return adev && adev->flags.is_coherent; +} + +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev); + 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..d14e777 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_dma_is_coherent(struct acpi_device *adev) +{ + return false; +} + #define ACPI_PTR(_ptr) (NULL) #endif /* !CONFIG_ACPI */ -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: linux-arm-kernel 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> --- NOTE: * Since there seem to be conflict opinions regarding how architecture should handle _CCA=0. So, I am proposing the CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by for each architecture to define behavior of the ACPI scanning code when _CCA=0. Let me know if this is acceptable. drivers/acpi/Kconfig | 6 +++++ drivers/acpi/acpi_platform.c | 4 ++- drivers/acpi/scan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ include/acpi/acpi_bus.h | 11 +++++++- include/linux/acpi.h | 5 ++++ 5 files changed, 86 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index ab2cbb5..dd386e9 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI config ACPI_SYSTEM_POWER_STATES_SUPPORT bool +config ACPI_MUST_HAVE_CCA + bool + +config ACPI_SUPPORT_CCA_ZERO + 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..a6feca4 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n", PTR_ERR(pdev)); - else + else { + acpi_setup_device_dma(adev, &pdev->dev); dev_dbg(&adev->dev, "created platform device %s\n", dev_name(&pdev->dev)); + } kfree(resources); return pdev; diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) kfree(pnp->unique_id); } +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) +{ + int coherent = acpi_dma_is_coherent(adev); + + /** + * Currently, we only support DMA for devices that _CCA=1 + * since this seems to be the case on most ACPI platforms. + * + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), + * we would rely on arch-specific cache maintenance for + * non-coherence DMA operations if architecture enables + * CONFIG_ACPI_SUPPORT_CCA_ZERO. + * + * For the case when _CCA is missing but platform requires it + * (i.e. is_coherent=0 && cca_seen=0), we do not call + * arch_setup_dma_ops() and fallback to arch-specific default + * handling. + */ + if (adev->flags.cca_seen) { + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) + return; + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); + } +} + +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 = acpi_dma_is_coherent(parent); + } 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_MUST_HAVE_CCA)) { + /* + * If architecture does not specify that _CCA is + * required for DMA-able devices (e.g. x86), + * we default to _CCA=1. + */ + cca = 1; + } else { + dev_err(&adev->dev, FW_BUG + "DMA is not setup due to missing _CCA.\n"); + } + } + + adev->flags.is_coherent = cca; + acpi_setup_device_dma(adev, &adev->dev); +} + void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, int type, unsigned long long sta) { @@ -2155,6 +2216,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..b804183 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 is_coherent:1; + u32 cca_seen:1; + u32 reserved:21; }; /* File System */ @@ -380,6 +382,13 @@ struct acpi_device { void (*remove)(struct acpi_device *); }; +static inline bool acpi_dma_is_coherent(struct acpi_device *adev) +{ + return adev && adev->flags.is_coherent; +} + +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev); + 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..d14e777 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_dma_is_coherent(struct acpi_device *adev) +{ + return false; +} + #define ACPI_PTR(_ptr) (NULL) #endif /* !CONFIG_ACPI */ -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Suravee Suthikulpanit 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> --- NOTE: * Since there seem to be conflict opinions regarding how architecture should handle _CCA=0. So, I am proposing the CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by for each architecture to define behavior of the ACPI scanning code when _CCA=0. Let me know if this is acceptable. drivers/acpi/Kconfig | 6 +++++ drivers/acpi/acpi_platform.c | 4 ++- drivers/acpi/scan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ include/acpi/acpi_bus.h | 11 +++++++- include/linux/acpi.h | 5 ++++ 5 files changed, 86 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index ab2cbb5..dd386e9 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI config ACPI_SYSTEM_POWER_STATES_SUPPORT bool +config ACPI_MUST_HAVE_CCA + bool + +config ACPI_SUPPORT_CCA_ZERO + 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..a6feca4 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n", PTR_ERR(pdev)); - else + else { + acpi_setup_device_dma(adev, &pdev->dev); dev_dbg(&adev->dev, "created platform device %s\n", dev_name(&pdev->dev)); + } kfree(resources); return pdev; diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) kfree(pnp->unique_id); } +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) +{ + int coherent = acpi_dma_is_coherent(adev); + + /** + * Currently, we only support DMA for devices that _CCA=1 + * since this seems to be the case on most ACPI platforms. + * + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), + * we would rely on arch-specific cache maintenance for + * non-coherence DMA operations if architecture enables + * CONFIG_ACPI_SUPPORT_CCA_ZERO. + * + * For the case when _CCA is missing but platform requires it + * (i.e. is_coherent=0 && cca_seen=0), we do not call + * arch_setup_dma_ops() and fallback to arch-specific default + * handling. + */ + if (adev->flags.cca_seen) { + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) + return; + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); + } +} + +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 = acpi_dma_is_coherent(parent); + } 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_MUST_HAVE_CCA)) { + /* + * If architecture does not specify that _CCA is + * required for DMA-able devices (e.g. x86), + * we default to _CCA=1. + */ + cca = 1; + } else { + dev_err(&adev->dev, FW_BUG + "DMA is not setup due to missing _CCA.\n"); + } + } + + adev->flags.is_coherent = cca; + acpi_setup_device_dma(adev, &adev->dev); +} + void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, int type, unsigned long long sta) { @@ -2155,6 +2216,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..b804183 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 is_coherent:1; + u32 cca_seen:1; + u32 reserved:21; }; /* File System */ @@ -380,6 +382,13 @@ struct acpi_device { void (*remove)(struct acpi_device *); }; +static inline bool acpi_dma_is_coherent(struct acpi_device *adev) +{ + return adev && adev->flags.is_coherent; +} + +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev); + 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..d14e777 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_dma_is_coherent(struct acpi_device *adev) +{ + return false; +} + #define ACPI_PTR(_ptr) (NULL) #endif /* !CONFIG_ACPI */ -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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> --- NOTE: * Since there seem to be conflict opinions regarding how architecture should handle _CCA=0. So, I am proposing the CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by for each architecture to define behavior of the ACPI scanning code when _CCA=0. Let me know if this is acceptable. drivers/acpi/Kconfig | 6 +++++ drivers/acpi/acpi_platform.c | 4 ++- drivers/acpi/scan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ include/acpi/acpi_bus.h | 11 +++++++- include/linux/acpi.h | 5 ++++ 5 files changed, 86 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index ab2cbb5..dd386e9 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI config ACPI_SYSTEM_POWER_STATES_SUPPORT bool +config ACPI_MUST_HAVE_CCA + bool + +config ACPI_SUPPORT_CCA_ZERO + 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..a6feca4 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n", PTR_ERR(pdev)); - else + else { + acpi_setup_device_dma(adev, &pdev->dev); dev_dbg(&adev->dev, "created platform device %s\n", dev_name(&pdev->dev)); + } kfree(resources); return pdev; diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) kfree(pnp->unique_id); } +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) +{ + int coherent = acpi_dma_is_coherent(adev); + + /** + * Currently, we only support DMA for devices that _CCA=1 + * since this seems to be the case on most ACPI platforms. + * + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), + * we would rely on arch-specific cache maintenance for + * non-coherence DMA operations if architecture enables + * CONFIG_ACPI_SUPPORT_CCA_ZERO. + * + * For the case when _CCA is missing but platform requires it + * (i.e. is_coherent=0 && cca_seen=0), we do not call + * arch_setup_dma_ops() and fallback to arch-specific default + * handling. + */ + if (adev->flags.cca_seen) { + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) + return; + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); + } +} + +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 = acpi_dma_is_coherent(parent); + } 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_MUST_HAVE_CCA)) { + /* + * If architecture does not specify that _CCA is + * required for DMA-able devices (e.g. x86), + * we default to _CCA=1. + */ + cca = 1; + } else { + dev_err(&adev->dev, FW_BUG + "DMA is not setup due to missing _CCA.\n"); + } + } + + adev->flags.is_coherent = cca; + acpi_setup_device_dma(adev, &adev->dev); +} + void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, int type, unsigned long long sta) { @@ -2155,6 +2216,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..b804183 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 is_coherent:1; + u32 cca_seen:1; + u32 reserved:21; }; /* File System */ @@ -380,6 +382,13 @@ struct acpi_device { void (*remove)(struct acpi_device *); }; +static inline bool acpi_dma_is_coherent(struct acpi_device *adev) +{ + return adev && adev->flags.is_coherent; +} + +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev); + 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..d14e777 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_dma_is_coherent(struct acpi_device *adev) +{ + return false; +} + #define ACPI_PTR(_ptr) (NULL) #endif /* !CONFIG_ACPI */ -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-05 15:12 ` Suravee Suthikulpanit @ 2015-05-05 20:36 ` Rafael J. Wysocki -1 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-05 20:36 UTC (permalink / raw) To: Suravee Suthikulpanit Cc: lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem, msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Mika Westerberg On Tuesday, May 05, 2015 10:12:05 AM 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> > --- > NOTE: > * Since there seem to be conflict opinions regarding how > architecture should handle _CCA=0. So, I am proposing the > CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by > for each architecture to define behavior of the ACPI > scanning code when _CCA=0. Let me know if this is acceptable. > > drivers/acpi/Kconfig | 6 +++++ > drivers/acpi/acpi_platform.c | 4 ++- > drivers/acpi/scan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ > include/acpi/acpi_bus.h | 11 +++++++- > include/linux/acpi.h | 5 ++++ > 5 files changed, 86 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index ab2cbb5..dd386e9 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI > config ACPI_SYSTEM_POWER_STATES_SUPPORT > bool > > +config ACPI_MUST_HAVE_CCA ACPI_CCA_REQUIRED maybe? > + bool > + > +config ACPI_SUPPORT_CCA_ZERO I guess this means "we support devices that can DMA, but are not coherent". right? > + 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..a6feca4 100644 > --- a/drivers/acpi/acpi_platform.c > +++ b/drivers/acpi/acpi_platform.c > @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) > if (IS_ERR(pdev)) > dev_err(&adev->dev, "platform device creation failed: %ld\n", > PTR_ERR(pdev)); > - else > + else { Please add braces to both branches when making such changes (as per CodingStyle). > + acpi_setup_device_dma(adev, &pdev->dev); Why do we need to do that here (for the second time)? > dev_dbg(&adev->dev, "created platform device %s\n", > dev_name(&pdev->dev)); > + } > > kfree(resources); > return pdev; > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) > kfree(pnp->unique_id); > } > > +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) > +{ > + int coherent = acpi_dma_is_coherent(adev); > + > + /** > + * Currently, we only support DMA for devices that _CCA=1 > + * since this seems to be the case on most ACPI platforms. > + * > + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), > + * we would rely on arch-specific cache maintenance for > + * non-coherence DMA operations if architecture enables > + * CONFIG_ACPI_SUPPORT_CCA_ZERO. > + * > + * For the case when _CCA is missing but platform requires it > + * (i.e. is_coherent=0 && cca_seen=0), we do not call > + * arch_setup_dma_ops() and fallback to arch-specific default > + * handling. > + */ > + if (adev->flags.cca_seen) { > + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) > + return; > + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); Oh dear. What about if (adev->flags.cca_seen && (coherent || IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))) arch_setup_dma_ops(dev, 0, 0, NULL, coherent); I wonder how this is going to affect x86/ia64 too? > + } > +} > + > +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 = acpi_dma_is_coherent(parent); > + } 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_MUST_HAVE_CCA)) { > + /* > + * If architecture does not specify that _CCA is > + * required for DMA-able devices (e.g. x86), > + * we default to _CCA=1. > + */ > + cca = 1; > + } else { > + dev_err(&adev->dev, FW_BUG > + "DMA is not setup due to missing _CCA.\n"); > + } > + } > + > + adev->flags.is_coherent = cca; > + acpi_setup_device_dma(adev, &adev->dev); > +} > + > void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, > int type, unsigned long long sta) > { > @@ -2155,6 +2216,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..b804183 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 is_coherent:1; > + u32 cca_seen:1; > + u32 reserved:21; That will conflict with a patch I've already queued up, but never mind. > }; > > /* File System */ > @@ -380,6 +382,13 @@ struct acpi_device { > void (*remove)(struct acpi_device *); > }; > > +static inline bool acpi_dma_is_coherent(struct acpi_device *adev) > +{ > + return adev && adev->flags.is_coherent; > +} > + > +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev); > + > 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..d14e777 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_dma_is_coherent(struct acpi_device *adev) > +{ > + return false; > +} > + > #define ACPI_PTR(_ptr) (NULL) > > #endif /* !CONFIG_ACPI */ > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-05 20:36 ` Rafael J. Wysocki 0 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-05 20:36 UTC (permalink / raw) To: linux-arm-kernel On Tuesday, May 05, 2015 10:12:05 AM 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> > --- > NOTE: > * Since there seem to be conflict opinions regarding how > architecture should handle _CCA=0. So, I am proposing the > CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by > for each architecture to define behavior of the ACPI > scanning code when _CCA=0. Let me know if this is acceptable. > > drivers/acpi/Kconfig | 6 +++++ > drivers/acpi/acpi_platform.c | 4 ++- > drivers/acpi/scan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ > include/acpi/acpi_bus.h | 11 +++++++- > include/linux/acpi.h | 5 ++++ > 5 files changed, 86 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index ab2cbb5..dd386e9 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI > config ACPI_SYSTEM_POWER_STATES_SUPPORT > bool > > +config ACPI_MUST_HAVE_CCA ACPI_CCA_REQUIRED maybe? > + bool > + > +config ACPI_SUPPORT_CCA_ZERO I guess this means "we support devices that can DMA, but are not coherent". right? > + 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..a6feca4 100644 > --- a/drivers/acpi/acpi_platform.c > +++ b/drivers/acpi/acpi_platform.c > @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) > if (IS_ERR(pdev)) > dev_err(&adev->dev, "platform device creation failed: %ld\n", > PTR_ERR(pdev)); > - else > + else { Please add braces to both branches when making such changes (as per CodingStyle). > + acpi_setup_device_dma(adev, &pdev->dev); Why do we need to do that here (for the second time)? > dev_dbg(&adev->dev, "created platform device %s\n", > dev_name(&pdev->dev)); > + } > > kfree(resources); > return pdev; > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) > kfree(pnp->unique_id); > } > > +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) > +{ > + int coherent = acpi_dma_is_coherent(adev); > + > + /** > + * Currently, we only support DMA for devices that _CCA=1 > + * since this seems to be the case on most ACPI platforms. > + * > + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), > + * we would rely on arch-specific cache maintenance for > + * non-coherence DMA operations if architecture enables > + * CONFIG_ACPI_SUPPORT_CCA_ZERO. > + * > + * For the case when _CCA is missing but platform requires it > + * (i.e. is_coherent=0 && cca_seen=0), we do not call > + * arch_setup_dma_ops() and fallback to arch-specific default > + * handling. > + */ > + if (adev->flags.cca_seen) { > + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) > + return; > + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); Oh dear. What about if (adev->flags.cca_seen && (coherent || IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))) arch_setup_dma_ops(dev, 0, 0, NULL, coherent); I wonder how this is going to affect x86/ia64 too? > + } > +} > + > +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 = acpi_dma_is_coherent(parent); > + } 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_MUST_HAVE_CCA)) { > + /* > + * If architecture does not specify that _CCA is > + * required for DMA-able devices (e.g. x86), > + * we default to _CCA=1. > + */ > + cca = 1; > + } else { > + dev_err(&adev->dev, FW_BUG > + "DMA is not setup due to missing _CCA.\n"); > + } > + } > + > + adev->flags.is_coherent = cca; > + acpi_setup_device_dma(adev, &adev->dev); > +} > + > void acpi_init_device_object(struct acpi_device *device, acpi_handle handle, > int type, unsigned long long sta) > { > @@ -2155,6 +2216,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..b804183 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 is_coherent:1; > + u32 cca_seen:1; > + u32 reserved:21; That will conflict with a patch I've already queued up, but never mind. > }; > > /* File System */ > @@ -380,6 +382,13 @@ struct acpi_device { > void (*remove)(struct acpi_device *); > }; > > +static inline bool acpi_dma_is_coherent(struct acpi_device *adev) > +{ > + return adev && adev->flags.is_coherent; > +} > + > +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev); > + > 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..d14e777 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_dma_is_coherent(struct acpi_device *adev) > +{ > + return false; > +} > + > #define ACPI_PTR(_ptr) (NULL) > > #endif /* !CONFIG_ACPI */ > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-05 20:36 ` Rafael J. Wysocki (?) @ 2015-05-06 4:15 ` Suravee Suthikulpanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-06 4:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem, msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Mika Westerberg [RESEND] On 5/5/15 15:36, Rafael J. Wysocki wrote: > On Tuesday, May 05, 2015 10:12:05 AM Suravee Suthikulpanit wrote: >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> index ab2cbb5..dd386e9 100644 >> --- a/drivers/acpi/Kconfig >> +++ b/drivers/acpi/Kconfig >> @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI >> config ACPI_SYSTEM_POWER_STATES_SUPPORT >> bool >> >> +config ACPI_MUST_HAVE_CCA > > ACPI_CCA_REQUIRED maybe? Sure. > >> + bool >> + >> +config ACPI_SUPPORT_CCA_ZERO > > I guess this means "we support devices that can DMA, but are not coherent". > right? Yes, basically when _CCA=0. >> + 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..a6feca4 100644 >> --- a/drivers/acpi/acpi_platform.c >> +++ b/drivers/acpi/acpi_platform.c >> @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) >> if (IS_ERR(pdev)) >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >> PTR_ERR(pdev)); >> - else >> + else { > > Please add braces to both branches when making such changes (as per CodingStyle). > OK. >> + acpi_setup_device_dma(adev, &pdev->dev); > > Why do we need to do that here (for the second time)? Because we are calling: acpi_create_platform_device() |--> platform_device_register_device_full() |-->platform_device_alloc() This creates platform_device, which allocate a new platform_device->dev. This is not the same as the original acpi_device->dev that was created during acpi_add_single_object(). So, we have to set up the device coherency again. >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >> index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) >> kfree(pnp->unique_id); >> } >> >> +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) >> +{ >> + int coherent = acpi_dma_is_coherent(adev); >> + >> + /** >> + * Currently, we only support DMA for devices that _CCA=1 >> + * since this seems to be the case on most ACPI platforms. >> + * >> + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), >> + * we would rely on arch-specific cache maintenance for >> + * non-coherence DMA operations if architecture enables >> + * CONFIG_ACPI_SUPPORT_CCA_ZERO. >> + * >> + * For the case when _CCA is missing but platform requires it >> + * (i.e. is_coherent=0 && cca_seen=0), we do not call >> + * arch_setup_dma_ops() and fallback to arch-specific default >> + * handling. >> + */ >> + if (adev->flags.cca_seen) { >> + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) >> + return; >> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > Oh dear. I made a mistake here. This logic should also call arch_setup_dma_ops() when cca_seen=0 and coherent=1 (e.g. when _CCA is not required and default to coherent when it is missing). The current logic doesn't do that. > > What about > > if (adev->flags.cca_seen && (coherent || IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))) > arch_setup_dma_ops(dev, 0, 0, NULL, coherent); What about: if (coherent || (adev->flags.cca_seen && IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > I wonder how this is going to affect x86/ia64 too? > This should not affect x86 since arch_setup_dma_ops() is currently not implement for x86, and default to NOP (see include/linux/dma-mapping.h). Also, on x86, _CCA is not required and default to 1 if missing. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-06 4:15 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-06 4:15 UTC (permalink / raw) To: linux-arm-kernel [RESEND] On 5/5/15 15:36, Rafael J. Wysocki wrote: > On Tuesday, May 05, 2015 10:12:05 AM Suravee Suthikulpanit wrote: >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> index ab2cbb5..dd386e9 100644 >> --- a/drivers/acpi/Kconfig >> +++ b/drivers/acpi/Kconfig >> @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI >> config ACPI_SYSTEM_POWER_STATES_SUPPORT >> bool >> >> +config ACPI_MUST_HAVE_CCA > > ACPI_CCA_REQUIRED maybe? Sure. > >> + bool >> + >> +config ACPI_SUPPORT_CCA_ZERO > > I guess this means "we support devices that can DMA, but are not coherent". > right? Yes, basically when _CCA=0. >> + 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..a6feca4 100644 >> --- a/drivers/acpi/acpi_platform.c >> +++ b/drivers/acpi/acpi_platform.c >> @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) >> if (IS_ERR(pdev)) >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >> PTR_ERR(pdev)); >> - else >> + else { > > Please add braces to both branches when making such changes (as per CodingStyle). > OK. >> + acpi_setup_device_dma(adev, &pdev->dev); > > Why do we need to do that here (for the second time)? Because we are calling: acpi_create_platform_device() |--> platform_device_register_device_full() |-->platform_device_alloc() This creates platform_device, which allocate a new platform_device->dev. This is not the same as the original acpi_device->dev that was created during acpi_add_single_object(). So, we have to set up the device coherency again. >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >> index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) >> kfree(pnp->unique_id); >> } >> >> +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) >> +{ >> + int coherent = acpi_dma_is_coherent(adev); >> + >> + /** >> + * Currently, we only support DMA for devices that _CCA=1 >> + * since this seems to be the case on most ACPI platforms. >> + * >> + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), >> + * we would rely on arch-specific cache maintenance for >> + * non-coherence DMA operations if architecture enables >> + * CONFIG_ACPI_SUPPORT_CCA_ZERO. >> + * >> + * For the case when _CCA is missing but platform requires it >> + * (i.e. is_coherent=0 && cca_seen=0), we do not call >> + * arch_setup_dma_ops() and fallback to arch-specific default >> + * handling. >> + */ >> + if (adev->flags.cca_seen) { >> + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) >> + return; >> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > Oh dear. I made a mistake here. This logic should also call arch_setup_dma_ops() when cca_seen=0 and coherent=1 (e.g. when _CCA is not required and default to coherent when it is missing). The current logic doesn't do that. > > What about > > if (adev->flags.cca_seen && (coherent || IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))) > arch_setup_dma_ops(dev, 0, 0, NULL, coherent); What about: if (coherent || (adev->flags.cca_seen && IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > I wonder how this is going to affect x86/ia64 too? > This should not affect x86 since arch_setup_dma_ops() is currently not implement for x86, and default to NOP (see include/linux/dma-mapping.h). Also, on x86, _CCA is not required and default to 1 if missing. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-06 4:15 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-06 4:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem, msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Mika Westerberg [RESEND] On 5/5/15 15:36, Rafael J. Wysocki wrote: > On Tuesday, May 05, 2015 10:12:05 AM Suravee Suthikulpanit wrote: >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> index ab2cbb5..dd386e9 100644 >> --- a/drivers/acpi/Kconfig >> +++ b/drivers/acpi/Kconfig >> @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI >> config ACPI_SYSTEM_POWER_STATES_SUPPORT >> bool >> >> +config ACPI_MUST_HAVE_CCA > > ACPI_CCA_REQUIRED maybe? Sure. > >> + bool >> + >> +config ACPI_SUPPORT_CCA_ZERO > > I guess this means "we support devices that can DMA, but are not coherent". > right? Yes, basically when _CCA=0. >> + 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..a6feca4 100644 >> --- a/drivers/acpi/acpi_platform.c >> +++ b/drivers/acpi/acpi_platform.c >> @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) >> if (IS_ERR(pdev)) >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >> PTR_ERR(pdev)); >> - else >> + else { > > Please add braces to both branches when making such changes (as per CodingStyle). > OK. >> + acpi_setup_device_dma(adev, &pdev->dev); > > Why do we need to do that here (for the second time)? Because we are calling: acpi_create_platform_device() |--> platform_device_register_device_full() |-->platform_device_alloc() This creates platform_device, which allocate a new platform_device->dev. This is not the same as the original acpi_device->dev that was created during acpi_add_single_object(). So, we have to set up the device coherency again. >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >> index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) >> kfree(pnp->unique_id); >> } >> >> +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) >> +{ >> + int coherent = acpi_dma_is_coherent(adev); >> + >> + /** >> + * Currently, we only support DMA for devices that _CCA=1 >> + * since this seems to be the case on most ACPI platforms. >> + * >> + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), >> + * we would rely on arch-specific cache maintenance for >> + * non-coherence DMA operations if architecture enables >> + * CONFIG_ACPI_SUPPORT_CCA_ZERO. >> + * >> + * For the case when _CCA is missing but platform requires it >> + * (i.e. is_coherent=0 && cca_seen=0), we do not call >> + * arch_setup_dma_ops() and fallback to arch-specific default >> + * handling. >> + */ >> + if (adev->flags.cca_seen) { >> + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) >> + return; >> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > Oh dear. I made a mistake here. This logic should also call arch_setup_dma_ops() when cca_seen=0 and coherent=1 (e.g. when _CCA is not required and default to coherent when it is missing). The current logic doesn't do that. > > What about > > if (adev->flags.cca_seen && (coherent || IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))) > arch_setup_dma_ops(dev, 0, 0, NULL, coherent); What about: if (coherent || (adev->flags.cca_seen && IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > I wonder how this is going to affect x86/ia64 too? > This should not affect x86 since arch_setup_dma_ops() is currently not implement for x86, and default to NOP (see include/linux/dma-mapping.h). Also, on x86, _CCA is not required and default to 1 if missing. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-06 4:15 ` Suravee Suthikulpanit @ 2015-05-06 22:21 ` Rafael J. Wysocki -1 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-06 22:21 UTC (permalink / raw) To: Suravee Suthikulpanit Cc: lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem, msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Mika Westerberg On Tuesday, May 05, 2015 11:15:37 PM Suravee Suthikulpanit wrote: > [RESEND] > > On 5/5/15 15:36, Rafael J. Wysocki wrote: > > On Tuesday, May 05, 2015 10:12:05 AM Suravee Suthikulpanit wrote: > >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > >> index ab2cbb5..dd386e9 100644 > >> --- a/drivers/acpi/Kconfig > >> +++ b/drivers/acpi/Kconfig > >> @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI > >> config ACPI_SYSTEM_POWER_STATES_SUPPORT > >> bool > >> > >> +config ACPI_MUST_HAVE_CCA > > > > ACPI_CCA_REQUIRED maybe? > > Sure. > > > > >> + bool > >> + > >> +config ACPI_SUPPORT_CCA_ZERO > > > > I guess this means "we support devices that can DMA, but are not coherent". > > right? > > Yes, basically when _CCA=0. So what about ARCH_SUPPORT_CACHE_INCOHERENT_DMA or something similar? > >> + 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..a6feca4 100644 > >> --- a/drivers/acpi/acpi_platform.c > >> +++ b/drivers/acpi/acpi_platform.c > >> @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) > >> if (IS_ERR(pdev)) > >> dev_err(&adev->dev, "platform device creation failed: %ld\n", > >> PTR_ERR(pdev)); > >> - else > >> + else { > > > > Please add braces to both branches when making such changes (as per CodingStyle). > > > > OK. > > >> + acpi_setup_device_dma(adev, &pdev->dev); > > > > Why do we need to do that here (for the second time)? > > Because we are calling: > acpi_create_platform_device() > |--> platform_device_register_device_full() > |-->platform_device_alloc() > > This creates platform_device, which allocate a new platform_device->dev. > This is not the same as the original acpi_device->dev that was created > during acpi_add_single_object(). So, we have to set up the device > coherency again. Ah, so the second arg is different now. Well, in that case, why do we need to set it up for the adev's dev member? > >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > >> index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) > >> kfree(pnp->unique_id); > >> } > >> > >> +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) > >> +{ > >> + int coherent = acpi_dma_is_coherent(adev); > >> + > >> + /** > >> + * Currently, we only support DMA for devices that _CCA=1 > >> + * since this seems to be the case on most ACPI platforms. > >> + * > >> + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), > >> + * we would rely on arch-specific cache maintenance for > >> + * non-coherence DMA operations if architecture enables > >> + * CONFIG_ACPI_SUPPORT_CCA_ZERO. > >> + * > >> + * For the case when _CCA is missing but platform requires it > >> + * (i.e. is_coherent=0 && cca_seen=0), we do not call > >> + * arch_setup_dma_ops() and fallback to arch-specific default > >> + * handling. > >> + */ > >> + if (adev->flags.cca_seen) { > >> + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) > >> + return; > >> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > > > Oh dear. > > I made a mistake here. This logic should also call arch_setup_dma_ops() > when cca_seen=0 and coherent=1 (e.g. when _CCA is not required and > default to coherent when it is missing). The current logic doesn't do that. > > > > > What about > > > > if (adev->flags.cca_seen && (coherent || IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))) > > arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > What about: > if (coherent || > (adev->flags.cca_seen && > IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) > arch_setup_dma_ops(dev, 0, 0, NULL, coherent); Yes, that works. > > I wonder how this is going to affect x86/ia64 too? > > > > This should not affect x86 since arch_setup_dma_ops() is currently not > implement for x86, and default to NOP (see include/linux/dma-mapping.h). OK > Also, on x86, _CCA is not required and default to 1 if missing. Well, that's the point. :-) -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-06 22:21 ` Rafael J. Wysocki 0 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-06 22:21 UTC (permalink / raw) To: linux-arm-kernel On Tuesday, May 05, 2015 11:15:37 PM Suravee Suthikulpanit wrote: > [RESEND] > > On 5/5/15 15:36, Rafael J. Wysocki wrote: > > On Tuesday, May 05, 2015 10:12:05 AM Suravee Suthikulpanit wrote: > >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > >> index ab2cbb5..dd386e9 100644 > >> --- a/drivers/acpi/Kconfig > >> +++ b/drivers/acpi/Kconfig > >> @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI > >> config ACPI_SYSTEM_POWER_STATES_SUPPORT > >> bool > >> > >> +config ACPI_MUST_HAVE_CCA > > > > ACPI_CCA_REQUIRED maybe? > > Sure. > > > > >> + bool > >> + > >> +config ACPI_SUPPORT_CCA_ZERO > > > > I guess this means "we support devices that can DMA, but are not coherent". > > right? > > Yes, basically when _CCA=0. So what about ARCH_SUPPORT_CACHE_INCOHERENT_DMA or something similar? > >> + 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..a6feca4 100644 > >> --- a/drivers/acpi/acpi_platform.c > >> +++ b/drivers/acpi/acpi_platform.c > >> @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) > >> if (IS_ERR(pdev)) > >> dev_err(&adev->dev, "platform device creation failed: %ld\n", > >> PTR_ERR(pdev)); > >> - else > >> + else { > > > > Please add braces to both branches when making such changes (as per CodingStyle). > > > > OK. > > >> + acpi_setup_device_dma(adev, &pdev->dev); > > > > Why do we need to do that here (for the second time)? > > Because we are calling: > acpi_create_platform_device() > |--> platform_device_register_device_full() > |-->platform_device_alloc() > > This creates platform_device, which allocate a new platform_device->dev. > This is not the same as the original acpi_device->dev that was created > during acpi_add_single_object(). So, we have to set up the device > coherency again. Ah, so the second arg is different now. Well, in that case, why do we need to set it up for the adev's dev member? > >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > >> index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) > >> kfree(pnp->unique_id); > >> } > >> > >> +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) > >> +{ > >> + int coherent = acpi_dma_is_coherent(adev); > >> + > >> + /** > >> + * Currently, we only support DMA for devices that _CCA=1 > >> + * since this seems to be the case on most ACPI platforms. > >> + * > >> + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), > >> + * we would rely on arch-specific cache maintenance for > >> + * non-coherence DMA operations if architecture enables > >> + * CONFIG_ACPI_SUPPORT_CCA_ZERO. > >> + * > >> + * For the case when _CCA is missing but platform requires it > >> + * (i.e. is_coherent=0 && cca_seen=0), we do not call > >> + * arch_setup_dma_ops() and fallback to arch-specific default > >> + * handling. > >> + */ > >> + if (adev->flags.cca_seen) { > >> + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) > >> + return; > >> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > > > Oh dear. > > I made a mistake here. This logic should also call arch_setup_dma_ops() > when cca_seen=0 and coherent=1 (e.g. when _CCA is not required and > default to coherent when it is missing). The current logic doesn't do that. > > > > > What about > > > > if (adev->flags.cca_seen && (coherent || IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO))) > > arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > What about: > if (coherent || > (adev->flags.cca_seen && > IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) > arch_setup_dma_ops(dev, 0, 0, NULL, coherent); Yes, that works. > > I wonder how this is going to affect x86/ia64 too? > > > > This should not affect x86 since arch_setup_dma_ops() is currently not > implement for x86, and default to NOP (see include/linux/dma-mapping.h). OK > Also, on x86, _CCA is not required and default to 1 if missing. Well, that's the point. :-) -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-06 22:21 ` Rafael J. Wysocki (?) @ 2015-05-06 22:16 ` Suravee Suthikulanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 22:16 UTC (permalink / raw) To: Rafael J. Wysocki Cc: lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem, msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Mika Westerberg On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: >>>> > >>+ bool >>>> > >>+ >>>> > >>+config ACPI_SUPPORT_CCA_ZERO >>> > > >>> > >I guess this means "we support devices that can DMA, but are not coherent". >>> > >right? >> > >> >Yes, basically when _CCA=0. > So what about > > ARCH_SUPPORT_CACHE_INCOHERENT_DMA Since this is specific to ACPI _CCA, I just want to be clear with the naming. > or something similar? > >>>> > >>+ 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..a6feca4 100644 >>>> > >>--- a/drivers/acpi/acpi_platform.c >>>> > >>+++ b/drivers/acpi/acpi_platform.c >>>> > >>@@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) >>>> > >> if (IS_ERR(pdev)) >>>> > >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >>>> > >> PTR_ERR(pdev)); >>>> > >>- else >>>> > >>+ else { >>> > > >>> > >Please add braces to both branches when making such changes (as per CodingStyle). >>> > > >> > >> >OK. >> > >>>> > >>+ acpi_setup_device_dma(adev, &pdev->dev); >>> > > >>> > >Why do we need to do that here (for the second time)? >> > >> >Because we are calling: >> > acpi_create_platform_device() >> > |--> platform_device_register_device_full() >> > |-->platform_device_alloc() >> > >> >This creates platform_device, which allocate a new platform_device->dev. >> >This is not the same as the original acpi_device->dev that was created >> >during acpi_add_single_object(). So, we have to set up the device >> >coherency again. > Ah, so the second arg is different now. > > Well, in that case, why do we need to set it up for the adev's dev member? > Just for sanity, since I don't know if adev->dev will be referenced anywhere else. This way, it's consistent for all copied of struct device generated. Lemme know if you think that is unnecessary. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-06 22:16 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 22:16 UTC (permalink / raw) To: linux-arm-kernel On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: >>>> > >>+ bool >>>> > >>+ >>>> > >>+config ACPI_SUPPORT_CCA_ZERO >>> > > >>> > >I guess this means "we support devices that can DMA, but are not coherent". >>> > >right? >> > >> >Yes, basically when _CCA=0. > So what about > > ARCH_SUPPORT_CACHE_INCOHERENT_DMA Since this is specific to ACPI _CCA, I just want to be clear with the naming. > or something similar? > >>>> > >>+ 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..a6feca4 100644 >>>> > >>--- a/drivers/acpi/acpi_platform.c >>>> > >>+++ b/drivers/acpi/acpi_platform.c >>>> > >>@@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) >>>> > >> if (IS_ERR(pdev)) >>>> > >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >>>> > >> PTR_ERR(pdev)); >>>> > >>- else >>>> > >>+ else { >>> > > >>> > >Please add braces to both branches when making such changes (as per CodingStyle). >>> > > >> > >> >OK. >> > >>>> > >>+ acpi_setup_device_dma(adev, &pdev->dev); >>> > > >>> > >Why do we need to do that here (for the second time)? >> > >> >Because we are calling: >> > acpi_create_platform_device() >> > |--> platform_device_register_device_full() >> > |-->platform_device_alloc() >> > >> >This creates platform_device, which allocate a new platform_device->dev. >> >This is not the same as the original acpi_device->dev that was created >> >during acpi_add_single_object(). So, we have to set up the device >> >coherency again. > Ah, so the second arg is different now. > > Well, in that case, why do we need to set it up for the adev's dev member? > Just for sanity, since I don't know if adev->dev will be referenced anywhere else. This way, it's consistent for all copied of struct device generated. Lemme know if you think that is unnecessary. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-06 22:16 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 22:16 UTC (permalink / raw) To: Rafael J. Wysocki Cc: lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem, msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Mika Westerberg On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: >>>> > >>+ bool >>>> > >>+ >>>> > >>+config ACPI_SUPPORT_CCA_ZERO >>> > > >>> > >I guess this means "we support devices that can DMA, but are not coherent". >>> > >right? >> > >> >Yes, basically when _CCA=0. > So what about > > ARCH_SUPPORT_CACHE_INCOHERENT_DMA Since this is specific to ACPI _CCA, I just want to be clear with the naming. > or something similar? > >>>> > >>+ 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..a6feca4 100644 >>>> > >>--- a/drivers/acpi/acpi_platform.c >>>> > >>+++ b/drivers/acpi/acpi_platform.c >>>> > >>@@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) >>>> > >> if (IS_ERR(pdev)) >>>> > >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >>>> > >> PTR_ERR(pdev)); >>>> > >>- else >>>> > >>+ else { >>> > > >>> > >Please add braces to both branches when making such changes (as per CodingStyle). >>> > > >> > >> >OK. >> > >>>> > >>+ acpi_setup_device_dma(adev, &pdev->dev); >>> > > >>> > >Why do we need to do that here (for the second time)? >> > >> >Because we are calling: >> > acpi_create_platform_device() >> > |--> platform_device_register_device_full() >> > |-->platform_device_alloc() >> > >> >This creates platform_device, which allocate a new platform_device->dev. >> >This is not the same as the original acpi_device->dev that was created >> >during acpi_add_single_object(). So, we have to set up the device >> >coherency again. > Ah, so the second arg is different now. > > Well, in that case, why do we need to set it up for the adev's dev member? > Just for sanity, since I don't know if adev->dev will be referenced anywhere else. This way, it's consistent for all copied of struct device generated. Lemme know if you think that is unnecessary. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Linaro-acpi] [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-06 22:16 ` Suravee Suthikulanit @ 2015-05-07 9:07 ` Arnd Bergmann -1 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-07 9:07 UTC (permalink / raw) To: linaro-acpi Cc: Suravee Suthikulanit, Rafael J. Wysocki, herbert, catalin.marinas, will.deacon, linux-kernel, linux-crypto, linux-acpi, netdev, Mika Westerberg, davem, linux-arm-kernel, lenb On Wednesday 06 May 2015 17:16:35 Suravee Suthikulanit wrote: > On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: > >>>> > >>+ bool > >>>> > >>+ > >>>> > >>+config ACPI_SUPPORT_CCA_ZERO > >>> > > > >>> > >I guess this means "we support devices that can DMA, but are not coherent". > >>> > >right? > >> > > >> >Yes, basically when _CCA=0. > > So what about > > > > ARCH_SUPPORT_CACHE_INCOHERENT_DMA > > Since this is specific to ACPI _CCA, I just want to be clear with the > naming. How about directly using the architecture names here, this is inherently architecture specific, and it's more likely that if another architecture gets added in the future that it will have other requirements. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* [Linaro-acpi] [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-07 9:07 ` Arnd Bergmann 0 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-07 9:07 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 06 May 2015 17:16:35 Suravee Suthikulanit wrote: > On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: > >>>> > >>+ bool > >>>> > >>+ > >>>> > >>+config ACPI_SUPPORT_CCA_ZERO > >>> > > > >>> > >I guess this means "we support devices that can DMA, but are not coherent". > >>> > >right? > >> > > >> >Yes, basically when _CCA=0. > > So what about > > > > ARCH_SUPPORT_CACHE_INCOHERENT_DMA > > Since this is specific to ACPI _CCA, I just want to be clear with the > naming. How about directly using the architecture names here, this is inherently architecture specific, and it's more likely that if another architecture gets added in the future that it will have other requirements. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Linaro-acpi] [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-07 9:07 ` Arnd Bergmann @ 2015-05-07 20:18 ` Rafael J. Wysocki -1 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-07 20:18 UTC (permalink / raw) To: Arnd Bergmann Cc: linaro-acpi, Suravee Suthikulanit, herbert, catalin.marinas, will.deacon, linux-kernel, linux-crypto, linux-acpi, netdev, Mika Westerberg, davem, linux-arm-kernel, lenb On Thursday, May 07, 2015 11:07:08 AM Arnd Bergmann wrote: > On Wednesday 06 May 2015 17:16:35 Suravee Suthikulanit wrote: > > On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: > > >>>> > >>+ bool > > >>>> > >>+ > > >>>> > >>+config ACPI_SUPPORT_CCA_ZERO > > >>> > > > > >>> > >I guess this means "we support devices that can DMA, but are not coherent". > > >>> > >right? > > >> > > > >> >Yes, basically when _CCA=0. > > > So what about > > > > > > ARCH_SUPPORT_CACHE_INCOHERENT_DMA > > > > Since this is specific to ACPI _CCA, I just want to be clear with the > > naming. > > How about directly using the architecture names here, this is inherently > architecture specific, and it's more likely that if another architecture > gets added in the future that it will have other requirements. Sounds reasonable to me. Rafael ^ permalink raw reply [flat|nested] 72+ messages in thread
* [Linaro-acpi] [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-07 20:18 ` Rafael J. Wysocki 0 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-07 20:18 UTC (permalink / raw) To: linux-arm-kernel On Thursday, May 07, 2015 11:07:08 AM Arnd Bergmann wrote: > On Wednesday 06 May 2015 17:16:35 Suravee Suthikulanit wrote: > > On 5/6/2015 5:21 PM, Rafael J. Wysocki wrote: > > >>>> > >>+ bool > > >>>> > >>+ > > >>>> > >>+config ACPI_SUPPORT_CCA_ZERO > > >>> > > > > >>> > >I guess this means "we support devices that can DMA, but are not coherent". > > >>> > >right? > > >> > > > >> >Yes, basically when _CCA=0. > > > So what about > > > > > > ARCH_SUPPORT_CACHE_INCOHERENT_DMA > > > > Since this is specific to ACPI _CCA, I just want to be clear with the > > naming. > > How about directly using the architecture names here, this is inherently > architecture specific, and it's more likely that if another architecture > gets added in the future that it will have other requirements. Sounds reasonable to me. Rafael ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-05 15:12 ` Suravee Suthikulpanit @ 2015-05-06 3:13 ` Hanjun Guo -1 siblings, 0 replies; 72+ messages in thread From: Hanjun Guo @ 2015-05-06 3:13 UTC (permalink / raw) To: Suravee Suthikulpanit, rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto On 2015年05月05日 23:12, 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> > --- > NOTE: > * Since there seem to be conflict opinions regarding how > architecture should handle _CCA=0. So, I am proposing the > CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by > for each architecture to define behavior of the ACPI > scanning code when _CCA=0. Let me know if this is acceptable. > > drivers/acpi/Kconfig | 6 +++++ > drivers/acpi/acpi_platform.c | 4 ++- > drivers/acpi/scan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ > include/acpi/acpi_bus.h | 11 +++++++- > include/linux/acpi.h | 5 ++++ > 5 files changed, 86 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index ab2cbb5..dd386e9 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI > config ACPI_SYSTEM_POWER_STATES_SUPPORT > bool > > +config ACPI_MUST_HAVE_CCA > + bool > + > +config ACPI_SUPPORT_CCA_ZERO > + 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..a6feca4 100644 > --- a/drivers/acpi/acpi_platform.c > +++ b/drivers/acpi/acpi_platform.c > @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) > if (IS_ERR(pdev)) > dev_err(&adev->dev, "platform device creation failed: %ld\n", > PTR_ERR(pdev)); > - else > + else { > + acpi_setup_device_dma(adev, &pdev->dev); > dev_dbg(&adev->dev, "created platform device %s\n", > dev_name(&pdev->dev)); > + } > > kfree(resources); > return pdev; > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) > kfree(pnp->unique_id); > } > > +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) I aasume adev->dev in struct *adev is the same as struct device *dev passed here, so > +{ > + int coherent = acpi_dma_is_coherent(adev); > + > + /** > + * Currently, we only support DMA for devices that _CCA=1 > + * since this seems to be the case on most ACPI platforms. > + * > + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), > + * we would rely on arch-specific cache maintenance for > + * non-coherence DMA operations if architecture enables > + * CONFIG_ACPI_SUPPORT_CCA_ZERO. > + * > + * For the case when _CCA is missing but platform requires it > + * (i.e. is_coherent=0 && cca_seen=0), we do not call > + * arch_setup_dma_ops() and fallback to arch-specific default > + * handling. > + */ > + if (adev->flags.cca_seen) { > + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) > + return; > + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); how about using &adev->dev here, and just pass struct acpi_device *adev for this function? Thanks Hanjun ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-06 3:13 ` Hanjun Guo 0 siblings, 0 replies; 72+ messages in thread From: Hanjun Guo @ 2015-05-06 3:13 UTC (permalink / raw) To: linux-arm-kernel On 2015?05?05? 23:12, 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> > --- > NOTE: > * Since there seem to be conflict opinions regarding how > architecture should handle _CCA=0. So, I am proposing the > CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by > for each architecture to define behavior of the ACPI > scanning code when _CCA=0. Let me know if this is acceptable. > > drivers/acpi/Kconfig | 6 +++++ > drivers/acpi/acpi_platform.c | 4 ++- > drivers/acpi/scan.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ > include/acpi/acpi_bus.h | 11 +++++++- > include/linux/acpi.h | 5 ++++ > 5 files changed, 86 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index ab2cbb5..dd386e9 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI > config ACPI_SYSTEM_POWER_STATES_SUPPORT > bool > > +config ACPI_MUST_HAVE_CCA > + bool > + > +config ACPI_SUPPORT_CCA_ZERO > + 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..a6feca4 100644 > --- a/drivers/acpi/acpi_platform.c > +++ b/drivers/acpi/acpi_platform.c > @@ -108,9 +108,11 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) > if (IS_ERR(pdev)) > dev_err(&adev->dev, "platform device creation failed: %ld\n", > PTR_ERR(pdev)); > - else > + else { > + acpi_setup_device_dma(adev, &pdev->dev); > dev_dbg(&adev->dev, "created platform device %s\n", > dev_name(&pdev->dev)); > + } > > kfree(resources); > return pdev; > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp) > kfree(pnp->unique_id); > } > > +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) I aasume adev->dev in struct *adev is the same as struct device *dev passed here, so > +{ > + int coherent = acpi_dma_is_coherent(adev); > + > + /** > + * Currently, we only support DMA for devices that _CCA=1 > + * since this seems to be the case on most ACPI platforms. > + * > + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), > + * we would rely on arch-specific cache maintenance for > + * non-coherence DMA operations if architecture enables > + * CONFIG_ACPI_SUPPORT_CCA_ZERO. > + * > + * For the case when _CCA is missing but platform requires it > + * (i.e. is_coherent=0 && cca_seen=0), we do not call > + * arch_setup_dma_ops() and fallback to arch-specific default > + * handling. > + */ > + if (adev->flags.cca_seen) { > + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) > + return; > + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); how about using &adev->dev here, and just pass struct acpi_device *adev for this function? Thanks Hanjun ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency 2015-05-06 3:13 ` Hanjun Guo (?) @ 2015-05-06 4:17 ` Suravee Suthikulpanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-06 4:17 UTC (permalink / raw) To: Hanjun Guo, rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto On 5/5/15 22:13, Hanjun Guo wrote: > On 2015年05月05日 23:12, 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> >> --- >> NOTE: >> * Since there seem to be conflict opinions regarding how >> architecture should handle _CCA=0. So, I am proposing the >> CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by >> for each architecture to define behavior of the ACPI >> scanning code when _CCA=0. Let me know if this is acceptable. >> >> drivers/acpi/Kconfig | 6 +++++ >> drivers/acpi/acpi_platform.c | 4 ++- >> drivers/acpi/scan.c | 62 >> ++++++++++++++++++++++++++++++++++++++++++++ >> include/acpi/acpi_bus.h | 11 +++++++- >> include/linux/acpi.h | 5 ++++ >> 5 files changed, 86 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> index ab2cbb5..dd386e9 100644 >> --- a/drivers/acpi/Kconfig >> +++ b/drivers/acpi/Kconfig >> @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI >> config ACPI_SYSTEM_POWER_STATES_SUPPORT >> bool >> >> +config ACPI_MUST_HAVE_CCA >> + bool >> + >> +config ACPI_SUPPORT_CCA_ZERO >> + 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..a6feca4 100644 >> --- a/drivers/acpi/acpi_platform.c >> +++ b/drivers/acpi/acpi_platform.c >> @@ -108,9 +108,11 @@ struct platform_device >> *acpi_create_platform_device(struct acpi_device *adev) >> if (IS_ERR(pdev)) >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >> PTR_ERR(pdev)); >> - else >> + else { >> + acpi_setup_device_dma(adev, &pdev->dev); >> dev_dbg(&adev->dev, "created platform device %s\n", >> dev_name(&pdev->dev)); >> + } >> >> kfree(resources); >> return pdev; >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >> index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp >> *pnp) >> kfree(pnp->unique_id); >> } >> >> +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) > > I aasume adev->dev in struct *adev is the same as struct device *dev > passed here, so > >> +{ >> + int coherent = acpi_dma_is_coherent(adev); >> + >> + /** >> + * Currently, we only support DMA for devices that _CCA=1 >> + * since this seems to be the case on most ACPI platforms. >> + * >> + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), >> + * we would rely on arch-specific cache maintenance for >> + * non-coherence DMA operations if architecture enables >> + * CONFIG_ACPI_SUPPORT_CCA_ZERO. >> + * >> + * For the case when _CCA is missing but platform requires it >> + * (i.e. is_coherent=0 && cca_seen=0), we do not call >> + * arch_setup_dma_ops() and fallback to arch-specific default >> + * handling. >> + */ >> + if (adev->flags.cca_seen) { >> + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) >> + return; >> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > how about using &adev->dev here, and just pass struct acpi_device *adev > for this function? Actually, I was using arch_setup_device_dma() in multiple places, and adev->dev is not necessary the same as *dev. However, I am refactoring this function in V3. Anyways, thanks for reviewing. Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-06 4:17 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-06 4:17 UTC (permalink / raw) To: linux-arm-kernel On 5/5/15 22:13, Hanjun Guo wrote: > On 2015?05?05? 23:12, 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> >> --- >> NOTE: >> * Since there seem to be conflict opinions regarding how >> architecture should handle _CCA=0. So, I am proposing the >> CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by >> for each architecture to define behavior of the ACPI >> scanning code when _CCA=0. Let me know if this is acceptable. >> >> drivers/acpi/Kconfig | 6 +++++ >> drivers/acpi/acpi_platform.c | 4 ++- >> drivers/acpi/scan.c | 62 >> ++++++++++++++++++++++++++++++++++++++++++++ >> include/acpi/acpi_bus.h | 11 +++++++- >> include/linux/acpi.h | 5 ++++ >> 5 files changed, 86 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> index ab2cbb5..dd386e9 100644 >> --- a/drivers/acpi/Kconfig >> +++ b/drivers/acpi/Kconfig >> @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI >> config ACPI_SYSTEM_POWER_STATES_SUPPORT >> bool >> >> +config ACPI_MUST_HAVE_CCA >> + bool >> + >> +config ACPI_SUPPORT_CCA_ZERO >> + 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..a6feca4 100644 >> --- a/drivers/acpi/acpi_platform.c >> +++ b/drivers/acpi/acpi_platform.c >> @@ -108,9 +108,11 @@ struct platform_device >> *acpi_create_platform_device(struct acpi_device *adev) >> if (IS_ERR(pdev)) >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >> PTR_ERR(pdev)); >> - else >> + else { >> + acpi_setup_device_dma(adev, &pdev->dev); >> dev_dbg(&adev->dev, "created platform device %s\n", >> dev_name(&pdev->dev)); >> + } >> >> kfree(resources); >> return pdev; >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >> index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp >> *pnp) >> kfree(pnp->unique_id); >> } >> >> +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) > > I aasume adev->dev in struct *adev is the same as struct device *dev > passed here, so > >> +{ >> + int coherent = acpi_dma_is_coherent(adev); >> + >> + /** >> + * Currently, we only support DMA for devices that _CCA=1 >> + * since this seems to be the case on most ACPI platforms. >> + * >> + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), >> + * we would rely on arch-specific cache maintenance for >> + * non-coherence DMA operations if architecture enables >> + * CONFIG_ACPI_SUPPORT_CCA_ZERO. >> + * >> + * For the case when _CCA is missing but platform requires it >> + * (i.e. is_coherent=0 && cca_seen=0), we do not call >> + * arch_setup_dma_ops() and fallback to arch-specific default >> + * handling. >> + */ >> + if (adev->flags.cca_seen) { >> + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) >> + return; >> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > how about using &adev->dev here, and just pass struct acpi_device *adev > for this function? Actually, I was using arch_setup_device_dma() in multiple places, and adev->dev is not necessary the same as *dev. However, I am refactoring this function in V3. Anyways, thanks for reviewing. Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency @ 2015-05-06 4:17 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-06 4:17 UTC (permalink / raw) To: Hanjun Guo, rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto On 5/5/15 22:13, Hanjun Guo wrote: > On 2015年05月05日 23:12, 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> >> --- >> NOTE: >> * Since there seem to be conflict opinions regarding how >> architecture should handle _CCA=0. So, I am proposing the >> CONFIG_ARCH_SUPPORT_CCA_ZERO, which can be specified by >> for each architecture to define behavior of the ACPI >> scanning code when _CCA=0. Let me know if this is acceptable. >> >> drivers/acpi/Kconfig | 6 +++++ >> drivers/acpi/acpi_platform.c | 4 ++- >> drivers/acpi/scan.c | 62 >> ++++++++++++++++++++++++++++++++++++++++++++ >> include/acpi/acpi_bus.h | 11 +++++++- >> include/linux/acpi.h | 5 ++++ >> 5 files changed, 86 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >> index ab2cbb5..dd386e9 100644 >> --- a/drivers/acpi/Kconfig >> +++ b/drivers/acpi/Kconfig >> @@ -54,6 +54,12 @@ config ACPI_GENERIC_GSI >> config ACPI_SYSTEM_POWER_STATES_SUPPORT >> bool >> >> +config ACPI_MUST_HAVE_CCA >> + bool >> + >> +config ACPI_SUPPORT_CCA_ZERO >> + 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..a6feca4 100644 >> --- a/drivers/acpi/acpi_platform.c >> +++ b/drivers/acpi/acpi_platform.c >> @@ -108,9 +108,11 @@ struct platform_device >> *acpi_create_platform_device(struct acpi_device *adev) >> if (IS_ERR(pdev)) >> dev_err(&adev->dev, "platform device creation failed: %ld\n", >> PTR_ERR(pdev)); >> - else >> + else { >> + acpi_setup_device_dma(adev, &pdev->dev); >> dev_dbg(&adev->dev, "created platform device %s\n", >> dev_name(&pdev->dev)); >> + } >> >> kfree(resources); >> return pdev; >> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >> index 849b699..ac33b29 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,66 @@ void acpi_free_pnp_ids(struct acpi_device_pnp >> *pnp) >> kfree(pnp->unique_id); >> } >> >> +void acpi_setup_device_dma(struct acpi_device *adev, struct device *dev) > > I aasume adev->dev in struct *adev is the same as struct device *dev > passed here, so > >> +{ >> + int coherent = acpi_dma_is_coherent(adev); >> + >> + /** >> + * Currently, we only support DMA for devices that _CCA=1 >> + * since this seems to be the case on most ACPI platforms. >> + * >> + * For the case when _CCA=0 (i.e. is_coherent=0 && cca_seen=1), >> + * we would rely on arch-specific cache maintenance for >> + * non-coherence DMA operations if architecture enables >> + * CONFIG_ACPI_SUPPORT_CCA_ZERO. >> + * >> + * For the case when _CCA is missing but platform requires it >> + * (i.e. is_coherent=0 && cca_seen=0), we do not call >> + * arch_setup_dma_ops() and fallback to arch-specific default >> + * handling. >> + */ >> + if (adev->flags.cca_seen) { >> + if (!coherent && !IS_ENABLED(CONFIG_ACPI_SUPPORT_CCA_ZERO)) >> + return; >> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent); > > how about using &adev->dev here, and just pass struct acpi_device *adev > for this function? Actually, I was using arch_setup_device_dma() in multiple places, and adev->dev is not necessary the same as *dev. However, I am refactoring this function in V3. Anyways, thanks for reviewing. Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-05 15:12 ` Suravee Suthikulpanit (?) (?) @ 2015-05-05 15:12 ` Suravee Suthikulpanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto >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. This patch introduces ACPI_MUST_HAVE_CCA in arm64 Kconfig to specify such requirement. In this case of missing _CCA, arm64 would assign dummy_dma_ops to disable DMA capability of the device. Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> --- arch/arm64/Kconfig | 2 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 104 +++++++++++++++++++++++++++++++++++ 3 files changed, 122 insertions(+), 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4269dba..4f4bbaaf 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1,7 +1,9 @@ config ARM64 def_bool y select ACPI_GENERIC_GSI if ACPI + select ACPI_MUST_HAVE_CCA if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI + select ACPI_SUPPORT_CCA_ZERO if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_GCOV_PROFILE_ALL 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..31d2b52 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -415,6 +415,110 @@ 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_for_cpu(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_single_for_device(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg_for_cpu(struct device *dev, + struct scatterlist *sgl, int nelems, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg_for_device(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_for_cpu, + .sync_single_for_device = __dummy_sync_single_for_device, + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, + .sync_sg_for_device = __dummy_sync_sg_for_device, + .mapping_error = __dummy_mapping_error, + .dma_supported = __dummy_dma_supported, +}; +EXPORT_SYMBOL(dummy_dma_ops); + static int __init arm64_dma_init(void) { int ret; -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: linux-arm-kernel >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. This patch introduces ACPI_MUST_HAVE_CCA in arm64 Kconfig to specify such requirement. In this case of missing _CCA, arm64 would assign dummy_dma_ops to disable DMA capability of the device. Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> --- arch/arm64/Kconfig | 2 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 104 +++++++++++++++++++++++++++++++++++ 3 files changed, 122 insertions(+), 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4269dba..4f4bbaaf 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1,7 +1,9 @@ config ARM64 def_bool y select ACPI_GENERIC_GSI if ACPI + select ACPI_MUST_HAVE_CCA if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI + select ACPI_SUPPORT_CCA_ZERO if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_GCOV_PROFILE_ALL 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..31d2b52 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -415,6 +415,110 @@ 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_for_cpu(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_single_for_device(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg_for_cpu(struct device *dev, + struct scatterlist *sgl, int nelems, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg_for_device(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_for_cpu, + .sync_single_for_device = __dummy_sync_single_for_device, + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, + .sync_sg_for_device = __dummy_sync_sg_for_device, + .mapping_error = __dummy_mapping_error, + .dma_supported = __dummy_dma_supported, +}; +EXPORT_SYMBOL(dummy_dma_ops); + static int __init arm64_dma_init(void) { int ret; -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Suravee Suthikulpanit >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. This patch introduces ACPI_MUST_HAVE_CCA in arm64 Kconfig to specify such requirement. In this case of missing _CCA, arm64 would assign dummy_dma_ops to disable DMA capability of the device. Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> --- arch/arm64/Kconfig | 2 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 104 +++++++++++++++++++++++++++++++++++ 3 files changed, 122 insertions(+), 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4269dba..4f4bbaaf 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1,7 +1,9 @@ config ARM64 def_bool y select ACPI_GENERIC_GSI if ACPI + select ACPI_MUST_HAVE_CCA if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI + select ACPI_SUPPORT_CCA_ZERO if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_GCOV_PROFILE_ALL 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..31d2b52 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -415,6 +415,110 @@ 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_for_cpu(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_single_for_device(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg_for_cpu(struct device *dev, + struct scatterlist *sgl, int nelems, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg_for_device(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_for_cpu, + .sync_single_for_device = __dummy_sync_single_for_device, + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, + .sync_sg_for_device = __dummy_sync_sg_for_device, + .mapping_error = __dummy_mapping_error, + .dma_supported = __dummy_dma_supported, +}; +EXPORT_SYMBOL(dummy_dma_ops); + static int __init arm64_dma_init(void) { int ret; -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto >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. This patch introduces ACPI_MUST_HAVE_CCA in arm64 Kconfig to specify such requirement. In this case of missing _CCA, arm64 would assign dummy_dma_ops to disable DMA capability of the device. Signed-off-by: Mark Salter <msalter@redhat.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> --- arch/arm64/Kconfig | 2 + arch/arm64/include/asm/dma-mapping.h | 18 +++++- arch/arm64/mm/dma-mapping.c | 104 +++++++++++++++++++++++++++++++++++ 3 files changed, 122 insertions(+), 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 4269dba..4f4bbaaf 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1,7 +1,9 @@ config ARM64 def_bool y select ACPI_GENERIC_GSI if ACPI + select ACPI_MUST_HAVE_CCA if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI + select ACPI_SUPPORT_CCA_ZERO if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_GCOV_PROFILE_ALL 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..31d2b52 100644 --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -415,6 +415,110 @@ 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_for_cpu(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_single_for_device(struct device *dev, + dma_addr_t dev_addr, size_t size, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg_for_cpu(struct device *dev, + struct scatterlist *sgl, int nelems, + enum dma_data_direction dir) +{ +} + +static void __dummy_sync_sg_for_device(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_for_cpu, + .sync_single_for_device = __dummy_sync_single_for_device, + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, + .sync_sg_for_device = __dummy_sync_sg_for_device, + .mapping_error = __dummy_mapping_error, + .dma_supported = __dummy_dma_supported, +}; +EXPORT_SYMBOL(dummy_dma_ops); + static int __init arm64_dma_init(void) { int ret; -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-05 15:12 ` Suravee Suthikulpanit (?) @ 2015-05-05 15:44 ` Arnd Bergmann -1 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-05 15:44 UTC (permalink / raw) To: linux-arm-kernel Cc: thomas.lendacky, msalter, herbert, al.stone, rjw, catalin.marinas, linaro-acpi, will.deacon, linux-kernel, linux-crypto, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, netdev, grant.likely, davem, lenb On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: > +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_for_cpu, > + .sync_single_for_device = __dummy_sync_single_for_device, > + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, > + .sync_sg_for_device = __dummy_sync_sg_for_device, > + .mapping_error = __dummy_mapping_error, > + .dma_supported = __dummy_dma_supported, > +}; > +EXPORT_SYMBOL(dummy_dma_ops); > + > This will clearly work, but I think it's easier to just leave the dma_mask pointer as NULL when creating the platform device, which should let the normal dma ops fail all the callbacks. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 15:44 ` Arnd Bergmann 0 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-05 15:44 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: > +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_for_cpu, > + .sync_single_for_device = __dummy_sync_single_for_device, > + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, > + .sync_sg_for_device = __dummy_sync_sg_for_device, > + .mapping_error = __dummy_mapping_error, > + .dma_supported = __dummy_dma_supported, > +}; > +EXPORT_SYMBOL(dummy_dma_ops); > + > This will clearly work, but I think it's easier to just leave the dma_mask pointer as NULL when creating the platform device, which should let the normal dma ops fail all the callbacks. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 15:44 ` Arnd Bergmann 0 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-05 15:44 UTC (permalink / raw) To: linux-arm-kernel Cc: Suravee Suthikulpanit, rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem, al.stone, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, msalter, grant.likely, linux-crypto On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: > +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_for_cpu, > + .sync_single_for_device = __dummy_sync_single_for_device, > + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, > + .sync_sg_for_device = __dummy_sync_sg_for_device, > + .mapping_error = __dummy_mapping_error, > + .dma_supported = __dummy_dma_supported, > +}; > +EXPORT_SYMBOL(dummy_dma_ops); > + > This will clearly work, but I think it's easier to just leave the dma_mask pointer as NULL when creating the platform device, which should let the normal dma ops fail all the callbacks. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-05 15:44 ` Arnd Bergmann (?) (?) @ 2015-05-05 16:09 ` Suravee Suthikulanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-05 16:09 UTC (permalink / raw) To: Arnd Bergmann, linux-arm-kernel Cc: thomas.lendacky, herbert, al.stone, linaro-acpi, catalin.marinas, msalter, rjw, linux-kernel, will.deacon, linux-crypto, linux-acpi, leo.duran, hanjun.guo, netdev, grant.likely, davem, lenb On 5/5/2015 10:44 AM, Arnd Bergmann wrote: > On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: >> +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_for_cpu, >> + .sync_single_for_device = __dummy_sync_single_for_device, >> + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, >> + .sync_sg_for_device = __dummy_sync_sg_for_device, >> + .mapping_error = __dummy_mapping_error, >> + .dma_supported = __dummy_dma_supported, >> +}; >> +EXPORT_SYMBOL(dummy_dma_ops); >> + >> > > This will clearly work, but I think it's easier to just leave > the dma_mask pointer as NULL when creating the platform device, > which should let the normal dma ops fail all the callbacks. > > Arnd > However, codes in several places are making use of dma_map_ops without checking if the ops are NULL (i.e. include/asm-generic/dma-mapping-common.h and in arch-specific implementation). If setting it to NULL is what we are planning to support, we would need to scrub the current code to put NULL check. Also, would you consider if that is safe to do going forward? Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 16:09 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-05 16:09 UTC (permalink / raw) To: linux-arm-kernel On 5/5/2015 10:44 AM, Arnd Bergmann wrote: > On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: >> +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_for_cpu, >> + .sync_single_for_device = __dummy_sync_single_for_device, >> + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, >> + .sync_sg_for_device = __dummy_sync_sg_for_device, >> + .mapping_error = __dummy_mapping_error, >> + .dma_supported = __dummy_dma_supported, >> +}; >> +EXPORT_SYMBOL(dummy_dma_ops); >> + >> > > This will clearly work, but I think it's easier to just leave > the dma_mask pointer as NULL when creating the platform device, > which should let the normal dma ops fail all the callbacks. > > Arnd > However, codes in several places are making use of dma_map_ops without checking if the ops are NULL (i.e. include/asm-generic/dma-mapping-common.h and in arch-specific implementation). If setting it to NULL is what we are planning to support, we would need to scrub the current code to put NULL check. Also, would you consider if that is safe to do going forward? Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 16:09 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-05 16:09 UTC (permalink / raw) To: Arnd Bergmann, linux-arm-kernel Cc: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem, al.stone, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, msalter, grant.likely, linux-crypto On 5/5/2015 10:44 AM, Arnd Bergmann wrote: > On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: >> +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_for_cpu, >> + .sync_single_for_device = __dummy_sync_single_for_device, >> + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, >> + .sync_sg_for_device = __dummy_sync_sg_for_device, >> + .mapping_error = __dummy_mapping_error, >> + .dma_supported = __dummy_dma_supported, >> +}; >> +EXPORT_SYMBOL(dummy_dma_ops); >> + >> > > This will clearly work, but I think it's easier to just leave > the dma_mask pointer as NULL when creating the platform device, > which should let the normal dma ops fail all the callbacks. > > Arnd > However, codes in several places are making use of dma_map_ops without checking if the ops are NULL (i.e. include/asm-generic/dma-mapping-common.h and in arch-specific implementation). If setting it to NULL is what we are planning to support, we would need to scrub the current code to put NULL check. Also, would you consider if that is safe to do going forward? Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 16:09 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-05 16:09 UTC (permalink / raw) To: Arnd Bergmann, linux-arm-kernel Cc: thomas.lendacky, herbert, al.stone, linaro-acpi, catalin.marinas, msalter, rjw, linux-kernel, will.deacon, linux-crypto, linux-acpi, leo.duran, hanjun.guo, netdev, grant.likely, davem, lenb On 5/5/2015 10:44 AM, Arnd Bergmann wrote: > On Tuesday 05 May 2015 10:12:06 Suravee Suthikulpanit wrote: >> +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_for_cpu, >> + .sync_single_for_device = __dummy_sync_single_for_device, >> + .sync_sg_for_cpu = __dummy_sync_sg_for_cpu, >> + .sync_sg_for_device = __dummy_sync_sg_for_device, >> + .mapping_error = __dummy_mapping_error, >> + .dma_supported = __dummy_dma_supported, >> +}; >> +EXPORT_SYMBOL(dummy_dma_ops); >> + >> > > This will clearly work, but I think it's easier to just leave > the dma_mask pointer as NULL when creating the platform device, > which should let the normal dma ops fail all the callbacks. > > Arnd > However, codes in several places are making use of dma_map_ops without checking if the ops are NULL (i.e. include/asm-generic/dma-mapping-common.h and in arch-specific implementation). If setting it to NULL is what we are planning to support, we would need to scrub the current code to put NULL check. Also, would you consider if that is safe to do going forward? Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-05 16:09 ` Suravee Suthikulanit @ 2015-05-05 16:12 ` Arnd Bergmann -1 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-05 16:12 UTC (permalink / raw) To: linaro-acpi Cc: Suravee Suthikulanit, linux-arm-kernel, herbert, catalin.marinas, rjw, linux-kernel, will.deacon, linux-crypto, linux-acpi, netdev, davem, lenb On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: > > However, codes in several places are making use of dma_map_ops without > checking if the ops are NULL (i.e. > include/asm-generic/dma-mapping-common.h and in arch-specific > implementation). If setting it to NULL is what we are planning to > support, we would need to scrub the current code to put NULL check. > Also, would you consider if that is safe to do going forward? > > I mean the dma_mask pointer, not dma_map_ops. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 16:12 ` Arnd Bergmann 0 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-05 16:12 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: > > However, codes in several places are making use of dma_map_ops without > checking if the ops are NULL (i.e. > include/asm-generic/dma-mapping-common.h and in arch-specific > implementation). If setting it to NULL is what we are planning to > support, we would need to scrub the current code to put NULL check. > Also, would you consider if that is safe to do going forward? > > I mean the dma_mask pointer, not dma_map_ops. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-05 16:12 ` Arnd Bergmann (?) @ 2015-05-05 16:13 ` Suravee Suthikulanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-05 16:13 UTC (permalink / raw) To: Arnd Bergmann, linaro-acpi Cc: linux-arm-kernel, herbert, catalin.marinas, rjw, linux-kernel, will.deacon, linux-crypto, linux-acpi, netdev, davem, lenb On 5/5/2015 11:12 AM, Arnd Bergmann wrote: > On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: >> >> However, codes in several places are making use of dma_map_ops without >> checking if the ops are NULL (i.e. >> include/asm-generic/dma-mapping-common.h and in arch-specific >> implementation). If setting it to NULL is what we are planning to >> support, we would need to scrub the current code to put NULL check. >> Also, would you consider if that is safe to do going forward? >> >> > > I mean the dma_mask pointer, not dma_map_ops. > > Arnd > Ah, got it. Sorry for confusion. Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 16:13 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-05 16:13 UTC (permalink / raw) To: linux-arm-kernel On 5/5/2015 11:12 AM, Arnd Bergmann wrote: > On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: >> >> However, codes in several places are making use of dma_map_ops without >> checking if the ops are NULL (i.e. >> include/asm-generic/dma-mapping-common.h and in arch-specific >> implementation). If setting it to NULL is what we are planning to >> support, we would need to scrub the current code to put NULL check. >> Also, would you consider if that is safe to do going forward? >> >> > > I mean the dma_mask pointer, not dma_map_ops. > > Arnd > Ah, got it. Sorry for confusion. Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 16:13 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-05 16:13 UTC (permalink / raw) To: Arnd Bergmann, linaro-acpi Cc: linux-arm-kernel, herbert, catalin.marinas, rjw, linux-kernel, will.deacon, linux-crypto, linux-acpi, netdev, davem, lenb On 5/5/2015 11:12 AM, Arnd Bergmann wrote: > On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: >> >> However, codes in several places are making use of dma_map_ops without >> checking if the ops are NULL (i.e. >> include/asm-generic/dma-mapping-common.h and in arch-specific >> implementation). If setting it to NULL is what we are planning to >> support, we would need to scrub the current code to put NULL check. >> Also, would you consider if that is safe to do going forward? >> >> > > I mean the dma_mask pointer, not dma_map_ops. > > Arnd > Ah, got it. Sorry for confusion. Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-05 16:13 ` Suravee Suthikulanit (?) @ 2015-05-05 16:24 ` Tom Lendacky -1 siblings, 0 replies; 72+ messages in thread From: Tom Lendacky @ 2015-05-05 16:24 UTC (permalink / raw) To: Suravee Suthikulanit, Arnd Bergmann, linaro-acpi Cc: rjw, herbert, catalin.marinas, will.deacon, linux-kernel, linux-acpi, linux-crypto, netdev, davem, linux-arm-kernel, lenb On 05/05/2015 11:13 AM, Suravee Suthikulanit wrote: > On 5/5/2015 11:12 AM, Arnd Bergmann wrote: >> On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: >>> >>> However, codes in several places are making use of dma_map_ops without >>> checking if the ops are NULL (i.e. >>> include/asm-generic/dma-mapping-common.h and in arch-specific >>> implementation). If setting it to NULL is what we are planning to >>> support, we would need to scrub the current code to put NULL check. >>> Also, would you consider if that is safe to do going forward? >>> >>> >> >> I mean the dma_mask pointer, not dma_map_ops. Except a lot of drivers will actually set the dma_mask pointer during probe (usually by setting dev->dma_mask = &dev->coherent_dma_mask or by calling dma_coerce_mask_and_coherent). So I think the dummy_dma_ops might be the safest way to go. Thanks, Tom >> >> Arnd >> > > Ah, got it. Sorry for confusion. > > Suravee > > _______________________________________________ > Linaro-acpi mailing list > Linaro-acpi@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-acpi ^ permalink raw reply [flat|nested] 72+ messages in thread
* [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 16:24 ` Tom Lendacky 0 siblings, 0 replies; 72+ messages in thread From: Tom Lendacky @ 2015-05-05 16:24 UTC (permalink / raw) To: linux-arm-kernel On 05/05/2015 11:13 AM, Suravee Suthikulanit wrote: > On 5/5/2015 11:12 AM, Arnd Bergmann wrote: >> On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: >>> >>> However, codes in several places are making use of dma_map_ops without >>> checking if the ops are NULL (i.e. >>> include/asm-generic/dma-mapping-common.h and in arch-specific >>> implementation). If setting it to NULL is what we are planning to >>> support, we would need to scrub the current code to put NULL check. >>> Also, would you consider if that is safe to do going forward? >>> >>> >> >> I mean the dma_mask pointer, not dma_map_ops. Except a lot of drivers will actually set the dma_mask pointer during probe (usually by setting dev->dma_mask = &dev->coherent_dma_mask or by calling dma_coerce_mask_and_coherent). So I think the dummy_dma_ops might be the safest way to go. Thanks, Tom >> >> Arnd >> > > Ah, got it. Sorry for confusion. > > Suravee > > _______________________________________________ > Linaro-acpi mailing list > Linaro-acpi at lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-acpi ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 16:24 ` Tom Lendacky 0 siblings, 0 replies; 72+ messages in thread From: Tom Lendacky @ 2015-05-05 16:24 UTC (permalink / raw) To: Suravee Suthikulanit, Arnd Bergmann, linaro-acpi Cc: rjw, herbert, catalin.marinas, will.deacon, linux-kernel, linux-acpi, linux-crypto, netdev, davem, linux-arm-kernel, lenb On 05/05/2015 11:13 AM, Suravee Suthikulanit wrote: > On 5/5/2015 11:12 AM, Arnd Bergmann wrote: >> On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: >>> >>> However, codes in several places are making use of dma_map_ops without >>> checking if the ops are NULL (i.e. >>> include/asm-generic/dma-mapping-common.h and in arch-specific >>> implementation). If setting it to NULL is what we are planning to >>> support, we would need to scrub the current code to put NULL check. >>> Also, would you consider if that is safe to do going forward? >>> >>> >> >> I mean the dma_mask pointer, not dma_map_ops. Except a lot of drivers will actually set the dma_mask pointer during probe (usually by setting dev->dma_mask = &dev->coherent_dma_mask or by calling dma_coerce_mask_and_coherent). So I think the dummy_dma_ops might be the safest way to go. Thanks, Tom >> >> Arnd >> > > Ah, got it. Sorry for confusion. > > Suravee > > _______________________________________________ > Linaro-acpi mailing list > Linaro-acpi@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-acpi ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-05 16:24 ` Tom Lendacky @ 2015-05-05 18:02 ` Arnd Bergmann -1 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-05 18:02 UTC (permalink / raw) To: Tom Lendacky Cc: Suravee Suthikulanit, linaro-acpi, rjw, herbert, catalin.marinas, will.deacon, linux-kernel, linux-acpi, linux-crypto, netdev, davem, linux-arm-kernel, lenb On Tuesday 05 May 2015 11:24:03 Tom Lendacky wrote: > On 05/05/2015 11:13 AM, Suravee Suthikulanit wrote: > > On 5/5/2015 11:12 AM, Arnd Bergmann wrote: > >> On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: > >>> > >>> However, codes in several places are making use of dma_map_ops without > >>> checking if the ops are NULL (i.e. > >>> include/asm-generic/dma-mapping-common.h and in arch-specific > >>> implementation). If setting it to NULL is what we are planning to > >>> support, we would need to scrub the current code to put NULL check. > >>> Also, would you consider if that is safe to do going forward? > >>> > >>> > >> > >> I mean the dma_mask pointer, not dma_map_ops. > > Except a lot of drivers will actually set the dma_mask pointer during > probe (usually by setting dev->dma_mask = &dev->coherent_dma_mask or by > calling dma_coerce_mask_and_coherent). So I think the dummy_dma_ops > might be the safest way to go. Those drivers are broken already, I don't think we should worry about them. Let's just fix them properly when we run into problems with them. Basically any use of dma_coerce_mask_and_coherent() is an annotation for a bug where a driver used to set dev->dma_mask = &dev->coherent_dma_mask manually. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-05 18:02 ` Arnd Bergmann 0 siblings, 0 replies; 72+ messages in thread From: Arnd Bergmann @ 2015-05-05 18:02 UTC (permalink / raw) To: linux-arm-kernel On Tuesday 05 May 2015 11:24:03 Tom Lendacky wrote: > On 05/05/2015 11:13 AM, Suravee Suthikulanit wrote: > > On 5/5/2015 11:12 AM, Arnd Bergmann wrote: > >> On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: > >>> > >>> However, codes in several places are making use of dma_map_ops without > >>> checking if the ops are NULL (i.e. > >>> include/asm-generic/dma-mapping-common.h and in arch-specific > >>> implementation). If setting it to NULL is what we are planning to > >>> support, we would need to scrub the current code to put NULL check. > >>> Also, would you consider if that is safe to do going forward? > >>> > >>> > >> > >> I mean the dma_mask pointer, not dma_map_ops. > > Except a lot of drivers will actually set the dma_mask pointer during > probe (usually by setting dev->dma_mask = &dev->coherent_dma_mask or by > calling dma_coerce_mask_and_coherent). So I think the dummy_dma_ops > might be the safest way to go. Those drivers are broken already, I don't think we should worry about them. Let's just fix them properly when we run into problems with them. Basically any use of dma_coerce_mask_and_coherent() is an annotation for a bug where a driver used to set dev->dma_mask = &dev->coherent_dma_mask manually. Arnd ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-05 15:12 ` Suravee Suthikulpanit (?) @ 2015-05-06 10:08 ` Robin Murphy -1 siblings, 0 replies; 72+ messages in thread From: Robin Murphy @ 2015-05-06 10:08 UTC (permalink / raw) To: Suravee Suthikulpanit, rjw, lenb, Catalin Marinas, Will Deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, msalter, grant.likely, linux-arm-kernel, linux-crypto Hi Suravee, On 05/05/15 16:12, 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. This patch introduces > ACPI_MUST_HAVE_CCA in arm64 Kconfig to specify such requirement. > > In this case of missing _CCA, arm64 would assign dummy_dma_ops > to disable DMA capability of the device. > > Signed-off-by: Mark Salter <msalter@redhat.com> > Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> > --- [...] > +static void __dummy_sync_single_for_cpu(struct device *dev, > + dma_addr_t dev_addr, size_t size, > + enum dma_data_direction dir) > +{ > +} > + > +static void __dummy_sync_single_for_device(struct device *dev, > + dma_addr_t dev_addr, size_t size, > + enum dma_data_direction dir) > +{ > +} Minor point, but I don't see the need to have multiple dummy functions with identical signatures - just have a generic dummy_sync_single and assign it to both ops. > +static void __dummy_sync_sg_for_cpu(struct device *dev, > + struct scatterlist *sgl, int nelems, > + enum dma_data_direction dir) > +{ > +} > + > +static void __dummy_sync_sg_for_device(struct device *dev, > + struct scatterlist *sgl, int nelems, > + enum dma_data_direction dir) > +{ > +} Ditto here with dummy_sync_sg. I wonder if there's any argument for putting the dummy DMA ops somewhere common, like drivers/base/dma-mapping.c? Robin. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-06 10:08 ` Robin Murphy 0 siblings, 0 replies; 72+ messages in thread From: Robin Murphy @ 2015-05-06 10:08 UTC (permalink / raw) To: linux-arm-kernel Hi Suravee, On 05/05/15 16:12, 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. This patch introduces > ACPI_MUST_HAVE_CCA in arm64 Kconfig to specify such requirement. > > In this case of missing _CCA, arm64 would assign dummy_dma_ops > to disable DMA capability of the device. > > Signed-off-by: Mark Salter <msalter@redhat.com> > Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> > --- [...] > +static void __dummy_sync_single_for_cpu(struct device *dev, > + dma_addr_t dev_addr, size_t size, > + enum dma_data_direction dir) > +{ > +} > + > +static void __dummy_sync_single_for_device(struct device *dev, > + dma_addr_t dev_addr, size_t size, > + enum dma_data_direction dir) > +{ > +} Minor point, but I don't see the need to have multiple dummy functions with identical signatures - just have a generic dummy_sync_single and assign it to both ops. > +static void __dummy_sync_sg_for_cpu(struct device *dev, > + struct scatterlist *sgl, int nelems, > + enum dma_data_direction dir) > +{ > +} > + > +static void __dummy_sync_sg_for_device(struct device *dev, > + struct scatterlist *sgl, int nelems, > + enum dma_data_direction dir) > +{ > +} Ditto here with dummy_sync_sg. I wonder if there's any argument for putting the dummy DMA ops somewhere common, like drivers/base/dma-mapping.c? Robin. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-06 10:08 ` Robin Murphy 0 siblings, 0 replies; 72+ messages in thread From: Robin Murphy @ 2015-05-06 10:08 UTC (permalink / raw) To: Suravee Suthikulpanit, rjw, lenb, Catalin Marinas, Will Deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, msalter, grant.likely, linux-arm-kernel, linux-crypto Hi Suravee, On 05/05/15 16:12, 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. This patch introduces > ACPI_MUST_HAVE_CCA in arm64 Kconfig to specify such requirement. > > In this case of missing _CCA, arm64 would assign dummy_dma_ops > to disable DMA capability of the device. > > Signed-off-by: Mark Salter <msalter@redhat.com> > Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> > --- [...] > +static void __dummy_sync_single_for_cpu(struct device *dev, > + dma_addr_t dev_addr, size_t size, > + enum dma_data_direction dir) > +{ > +} > + > +static void __dummy_sync_single_for_device(struct device *dev, > + dma_addr_t dev_addr, size_t size, > + enum dma_data_direction dir) > +{ > +} Minor point, but I don't see the need to have multiple dummy functions with identical signatures - just have a generic dummy_sync_single and assign it to both ops. > +static void __dummy_sync_sg_for_cpu(struct device *dev, > + struct scatterlist *sgl, int nelems, > + enum dma_data_direction dir) > +{ > +} > + > +static void __dummy_sync_sg_for_device(struct device *dev, > + struct scatterlist *sgl, int nelems, > + enum dma_data_direction dir) > +{ > +} Ditto here with dummy_sync_sg. I wonder if there's any argument for putting the dummy DMA ops somewhere common, like drivers/base/dma-mapping.c? Robin. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object 2015-05-06 10:08 ` Robin Murphy (?) @ 2015-05-06 14:34 ` Suravee Suthikulanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 14:34 UTC (permalink / raw) To: Robin Murphy, rjw, lenb, Catalin Marinas, Will Deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, msalter, grant.likely, linux-arm-kernel, linux-crypto On 5/6/2015 5:08 AM, Robin Murphy wrote: > [...] >> +static void __dummy_sync_single_for_cpu(struct device *dev, >> + dma_addr_t dev_addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> +} >> + >> +static void __dummy_sync_single_for_device(struct device *dev, >> + dma_addr_t dev_addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> +} > > Minor point, but I don't see the need to have multiple dummy functions > with identical signatures - just have a generic dummy_sync_single and > assign it to both ops. > >> +static void __dummy_sync_sg_for_cpu(struct device *dev, >> + struct scatterlist *sgl, int nelems, >> + enum dma_data_direction dir) >> +{ >> +} >> + >> +static void __dummy_sync_sg_for_device(struct device *dev, >> + struct scatterlist *sgl, int nelems, >> + enum dma_data_direction dir) >> +{ >> +} > > Ditto here with dummy_sync_sg. Hi Robin, Good point. I'll take care of that in V3. > > I wonder if there's any argument for putting the dummy DMA ops somewhere > common, like drivers/base/dma-mapping.c? > > Robin. Hm.. If this approach will be adopted by other architectures, then it would make sense. Currently, this is only used by arm64. So, I think it is okay to leave this here for now. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-06 14:34 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 14:34 UTC (permalink / raw) To: linux-arm-kernel On 5/6/2015 5:08 AM, Robin Murphy wrote: > [...] >> +static void __dummy_sync_single_for_cpu(struct device *dev, >> + dma_addr_t dev_addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> +} >> + >> +static void __dummy_sync_single_for_device(struct device *dev, >> + dma_addr_t dev_addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> +} > > Minor point, but I don't see the need to have multiple dummy functions > with identical signatures - just have a generic dummy_sync_single and > assign it to both ops. > >> +static void __dummy_sync_sg_for_cpu(struct device *dev, >> + struct scatterlist *sgl, int nelems, >> + enum dma_data_direction dir) >> +{ >> +} >> + >> +static void __dummy_sync_sg_for_device(struct device *dev, >> + struct scatterlist *sgl, int nelems, >> + enum dma_data_direction dir) >> +{ >> +} > > Ditto here with dummy_sync_sg. Hi Robin, Good point. I'll take care of that in V3. > > I wonder if there's any argument for putting the dummy DMA ops somewhere > common, like drivers/base/dma-mapping.c? > > Robin. Hm.. If this approach will be adopted by other architectures, then it would make sense. Currently, this is only used by arm64. So, I think it is okay to leave this here for now. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object @ 2015-05-06 14:34 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 14:34 UTC (permalink / raw) To: Robin Murphy, rjw, lenb, Catalin Marinas, Will Deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, msalter, grant.likely, linux-arm-kernel, linux-crypto On 5/6/2015 5:08 AM, Robin Murphy wrote: > [...] >> +static void __dummy_sync_single_for_cpu(struct device *dev, >> + dma_addr_t dev_addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> +} >> + >> +static void __dummy_sync_single_for_device(struct device *dev, >> + dma_addr_t dev_addr, size_t size, >> + enum dma_data_direction dir) >> +{ >> +} > > Minor point, but I don't see the need to have multiple dummy functions > with identical signatures - just have a generic dummy_sync_single and > assign it to both ops. > >> +static void __dummy_sync_sg_for_cpu(struct device *dev, >> + struct scatterlist *sgl, int nelems, >> + enum dma_data_direction dir) >> +{ >> +} >> + >> +static void __dummy_sync_sg_for_device(struct device *dev, >> + struct scatterlist *sgl, int nelems, >> + enum dma_data_direction dir) >> +{ >> +} > > Ditto here with dummy_sync_sg. Hi Robin, Good point. I'll take care of that in V3. > > I wonder if there's any argument for putting the dummy DMA ops somewhere > common, like drivers/base/dma-mapping.c? > > Robin. Hm.. If this approach will be adopted by other architectures, then it would make sense. Currently, this is only used by arm64. So, I think it is okay to leave this here for now. Thanks, Suravee ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() 2015-05-05 15:12 ` Suravee Suthikulpanit (?) (?) @ 2015-05-05 15:12 ` Suravee Suthikulpanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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 | 12 ++++++++++++ include/linux/property.h | 2 ++ 2 files changed, 14 insertions(+) diff --git a/drivers/base/property.c b/drivers/base/property.c index 1d0b116..8123c6e 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,14 @@ 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) +{ + if (IS_ENABLED(CONFIG_OF) && dev->of_node) + return of_dma_is_coherent(dev->of_node); + else if (has_acpi_companion(dev)) + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); + + return false; +} +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_ */ -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: linux-arm-kernel 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 | 12 ++++++++++++ include/linux/property.h | 2 ++ 2 files changed, 14 insertions(+) diff --git a/drivers/base/property.c b/drivers/base/property.c index 1d0b116..8123c6e 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,14 @@ 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) +{ + if (IS_ENABLED(CONFIG_OF) && dev->of_node) + return of_dma_is_coherent(dev->of_node); + else if (has_acpi_companion(dev)) + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); + + return false; +} +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_ */ -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Suravee Suthikulpanit 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 | 12 ++++++++++++ include/linux/property.h | 2 ++ 2 files changed, 14 insertions(+) diff --git a/drivers/base/property.c b/drivers/base/property.c index 1d0b116..8123c6e 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,14 @@ 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) +{ + if (IS_ENABLED(CONFIG_OF) && dev->of_node) + return of_dma_is_coherent(dev->of_node); + else if (has_acpi_companion(dev)) + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); + + return false; +} +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_ */ -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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 | 12 ++++++++++++ include/linux/property.h | 2 ++ 2 files changed, 14 insertions(+) diff --git a/drivers/base/property.c b/drivers/base/property.c index 1d0b116..8123c6e 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,14 @@ 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) +{ + if (IS_ENABLED(CONFIG_OF) && dev->of_node) + return of_dma_is_coherent(dev->of_node); + else if (has_acpi_companion(dev)) + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); + + return false; +} +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_ */ -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() 2015-05-05 15:12 ` Suravee Suthikulpanit (?) @ 2015-05-06 23:52 ` Suravee Suthikulanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 23:52 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto Rafael, Any comments on this patch? Thanks, Suravee On 5/5/2015 10:12 AM, Suravee Suthikulpanit wrote: > 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 | 12 ++++++++++++ > include/linux/property.h | 2 ++ > 2 files changed, 14 insertions(+) > > diff --git a/drivers/base/property.c b/drivers/base/property.c > index 1d0b116..8123c6e 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,14 @@ 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) > +{ > + if (IS_ENABLED(CONFIG_OF) && dev->of_node) > + return of_dma_is_coherent(dev->of_node); > + else if (has_acpi_companion(dev)) > + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); > + > + return false; > +} > +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_ */ > ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() @ 2015-05-06 23:52 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 23:52 UTC (permalink / raw) To: linux-arm-kernel Rafael, Any comments on this patch? Thanks, Suravee On 5/5/2015 10:12 AM, Suravee Suthikulpanit wrote: > 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 | 12 ++++++++++++ > include/linux/property.h | 2 ++ > 2 files changed, 14 insertions(+) > > diff --git a/drivers/base/property.c b/drivers/base/property.c > index 1d0b116..8123c6e 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,14 @@ 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) > +{ > + if (IS_ENABLED(CONFIG_OF) && dev->of_node) > + return of_dma_is_coherent(dev->of_node); > + else if (has_acpi_companion(dev)) > + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); > + > + return false; > +} > +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_ */ > ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() @ 2015-05-06 23:52 ` Suravee Suthikulanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulanit @ 2015-05-06 23:52 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto Rafael, Any comments on this patch? Thanks, Suravee On 5/5/2015 10:12 AM, Suravee Suthikulpanit wrote: > 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 | 12 ++++++++++++ > include/linux/property.h | 2 ++ > 2 files changed, 14 insertions(+) > > diff --git a/drivers/base/property.c b/drivers/base/property.c > index 1d0b116..8123c6e 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,14 @@ 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) > +{ > + if (IS_ENABLED(CONFIG_OF) && dev->of_node) > + return of_dma_is_coherent(dev->of_node); > + else if (has_acpi_companion(dev)) > + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); > + > + return false; > +} > +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_ */ > ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() 2015-05-06 23:52 ` Suravee Suthikulanit (?) @ 2015-05-06 23:58 ` Rafael J. Wysocki -1 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-06 23:58 UTC (permalink / raw) To: Suravee Suthikulanit Cc: Rafael J. Wysocki, Len Brown, Catalin Marinas, Will Deacon, thomas.lendacky, herbert, David Miller, msalter, Hanjun Guo, Al Stone, Grant Likely, Arnd Bergmann, leo.duran, linux-arm-kernel, ACPI Devel Maling List, Linux Kernel Mailing List, linaro-acpi, netdev, linux-crypto On Thu, May 7, 2015 at 1:52 AM, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote: > Rafael, > > Any comments on this patch? Well, as long as acpi_dma_is_coherent() does the right thing on all architectures, I have no objections. Thanks, Rafael > On 5/5/2015 10:12 AM, Suravee Suthikulpanit wrote: >> >> 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 | 12 ++++++++++++ >> include/linux/property.h | 2 ++ >> 2 files changed, 14 insertions(+) >> >> diff --git a/drivers/base/property.c b/drivers/base/property.c >> index 1d0b116..8123c6e 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,14 @@ 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) >> +{ >> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) >> + return of_dma_is_coherent(dev->of_node); >> + else if (has_acpi_companion(dev)) >> + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); >> + >> + return false; >> +} >> +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_ */ >> > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() @ 2015-05-06 23:58 ` Rafael J. Wysocki 0 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-06 23:58 UTC (permalink / raw) To: linux-arm-kernel On Thu, May 7, 2015 at 1:52 AM, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote: > Rafael, > > Any comments on this patch? Well, as long as acpi_dma_is_coherent() does the right thing on all architectures, I have no objections. Thanks, Rafael > On 5/5/2015 10:12 AM, Suravee Suthikulpanit wrote: >> >> 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 | 12 ++++++++++++ >> include/linux/property.h | 2 ++ >> 2 files changed, 14 insertions(+) >> >> diff --git a/drivers/base/property.c b/drivers/base/property.c >> index 1d0b116..8123c6e 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,14 @@ 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) >> +{ >> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) >> + return of_dma_is_coherent(dev->of_node); >> + else if (has_acpi_companion(dev)) >> + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); >> + >> + return false; >> +} >> +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_ */ >> > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() @ 2015-05-06 23:58 ` Rafael J. Wysocki 0 siblings, 0 replies; 72+ messages in thread From: Rafael J. Wysocki @ 2015-05-06 23:58 UTC (permalink / raw) To: Suravee Suthikulanit Cc: Rafael J. Wysocki, Len Brown, Catalin Marinas, Will Deacon, thomas.lendacky, herbert, David Miller, msalter, Hanjun Guo, Al Stone, Grant Likely, Arnd Bergmann, leo.duran, linux-arm-kernel, ACPI Devel Maling List, Linux Kernel Mailing List, linaro-acpi, netdev, linux-crypto On Thu, May 7, 2015 at 1:52 AM, Suravee Suthikulanit <suravee.suthikulpanit@amd.com> wrote: > Rafael, > > Any comments on this patch? Well, as long as acpi_dma_is_coherent() does the right thing on all architectures, I have no objections. Thanks, Rafael > On 5/5/2015 10:12 AM, Suravee Suthikulpanit wrote: >> >> 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 | 12 ++++++++++++ >> include/linux/property.h | 2 ++ >> 2 files changed, 14 insertions(+) >> >> diff --git a/drivers/base/property.c b/drivers/base/property.c >> index 1d0b116..8123c6e 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,14 @@ 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) >> +{ >> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) >> + return of_dma_is_coherent(dev->of_node); >> + else if (has_acpi_companion(dev)) >> + return acpi_dma_is_coherent(acpi_node(dev->fwnode)); >> + >> + return false; >> +} >> +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_ */ >> > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 72+ messages in thread
* [V2 PATCH 4/5] crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() 2015-05-05 15:12 ` Suravee Suthikulpanit (?) (?) @ 2015-05-05 15:12 ` Suravee Suthikulpanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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(). CC: Herbert Xu <herbert@gondor.apana.org.au> CC: David S. Miller <davem@davemloft.net> 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 -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 4/5] crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: linux-arm-kernel 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(). CC: Herbert Xu <herbert@gondor.apana.org.au> CC: David S. Miller <davem@davemloft.net> 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 -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 4/5] crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Suravee Suthikulpanit 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(). CC: Herbert Xu <herbert@gondor.apana.org.au> CC: David S. Miller <davem@davemloft.net> 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 -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 4/5] crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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(). CC: Herbert Xu <herbert@gondor.apana.org.au> CC: David S. Miller <davem@davemloft.net> 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 -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 5/5] amd-xgbe: Unify coherency checking logic with device_dma_is_coherent() 2015-05-05 15:12 ` Suravee Suthikulpanit (?) (?) @ 2015-05-05 15:12 ` Suravee Suthikulpanit -1 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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(). CC: David S. Miller <davem@davemloft.net> 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; -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 5/5] amd-xgbe: Unify coherency checking logic with device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: linux-arm-kernel 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(). CC: David S. Miller <davem@davemloft.net> 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; -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 5/5] amd-xgbe: Unify coherency checking logic with device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: msalter, hanjun.guo, al.stone, grant.likely, arnd, leo.duran, linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi, netdev, linux-crypto, Suravee Suthikulpanit 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(). CC: David S. Miller <davem@davemloft.net> 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; -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [V2 PATCH 5/5] amd-xgbe: Unify coherency checking logic with device_dma_is_coherent() @ 2015-05-05 15:12 ` Suravee Suthikulpanit 0 siblings, 0 replies; 72+ messages in thread From: Suravee Suthikulpanit @ 2015-05-05 15:12 UTC (permalink / raw) To: rjw, lenb, catalin.marinas, will.deacon, thomas.lendacky, herbert, davem Cc: al.stone, arnd, linaro-acpi, netdev, linux-kernel, linux-acpi, leo.duran, hanjun.guo, Suravee Suthikulpanit, msalter, grant.likely, linux-arm-kernel, linux-crypto 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(). CC: David S. Miller <davem@davemloft.net> 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; -- 2.1.0 ^ permalink raw reply related [flat|nested] 72+ messages in thread
end of thread, other threads:[~2015-05-07 20:18 UTC | newest] Thread overview: 72+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-05-05 15:12 [V2 PATCH 0/5] Introduce ACPI _CCA support and device_dma_is_coherent API Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 20:36 ` Rafael J. Wysocki 2015-05-05 20:36 ` Rafael J. Wysocki 2015-05-06 4:15 ` Suravee Suthikulpanit 2015-05-06 4:15 ` Suravee Suthikulpanit 2015-05-06 4:15 ` Suravee Suthikulpanit 2015-05-06 22:21 ` Rafael J. Wysocki 2015-05-06 22:21 ` Rafael J. Wysocki 2015-05-06 22:16 ` Suravee Suthikulanit 2015-05-06 22:16 ` Suravee Suthikulanit 2015-05-06 22:16 ` Suravee Suthikulanit 2015-05-07 9:07 ` [Linaro-acpi] " Arnd Bergmann 2015-05-07 9:07 ` Arnd Bergmann 2015-05-07 20:18 ` Rafael J. Wysocki 2015-05-07 20:18 ` Rafael J. Wysocki 2015-05-06 3:13 ` Hanjun Guo 2015-05-06 3:13 ` Hanjun Guo 2015-05-06 4:17 ` Suravee Suthikulpanit 2015-05-06 4:17 ` Suravee Suthikulpanit 2015-05-06 4:17 ` Suravee Suthikulpanit 2015-05-05 15:12 ` [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:44 ` Arnd Bergmann 2015-05-05 15:44 ` Arnd Bergmann 2015-05-05 15:44 ` Arnd Bergmann 2015-05-05 16:09 ` Suravee Suthikulanit 2015-05-05 16:09 ` Suravee Suthikulanit 2015-05-05 16:09 ` Suravee Suthikulanit 2015-05-05 16:09 ` Suravee Suthikulanit 2015-05-05 16:12 ` [Linaro-acpi] " Arnd Bergmann 2015-05-05 16:12 ` Arnd Bergmann 2015-05-05 16:13 ` Suravee Suthikulanit 2015-05-05 16:13 ` Suravee Suthikulanit 2015-05-05 16:13 ` Suravee Suthikulanit 2015-05-05 16:24 ` Tom Lendacky 2015-05-05 16:24 ` Tom Lendacky 2015-05-05 16:24 ` Tom Lendacky 2015-05-05 18:02 ` Arnd Bergmann 2015-05-05 18:02 ` Arnd Bergmann 2015-05-06 10:08 ` Robin Murphy 2015-05-06 10:08 ` Robin Murphy 2015-05-06 10:08 ` Robin Murphy 2015-05-06 14:34 ` Suravee Suthikulanit 2015-05-06 14:34 ` Suravee Suthikulanit 2015-05-06 14:34 ` Suravee Suthikulanit 2015-05-05 15:12 ` [V2 PATCH 3/5] device property: Introduces device_dma_is_coherent() Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-06 23:52 ` Suravee Suthikulanit 2015-05-06 23:52 ` Suravee Suthikulanit 2015-05-06 23:52 ` Suravee Suthikulanit 2015-05-06 23:58 ` Rafael J. Wysocki 2015-05-06 23:58 ` Rafael J. Wysocki 2015-05-06 23:58 ` Rafael J. Wysocki 2015-05-05 15:12 ` [V2 PATCH 4/5] crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` [V2 PATCH 5/5] amd-xgbe: " Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit 2015-05-05 15:12 ` Suravee Suthikulpanit
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.