Thread (32 messages) 32 messages, 8 authors, 2015-05-21

[V4 PATCH 1/6] ACPI / scan: Parse _CCA and setup device coherency

From: suravee.suthikulpanit@amd.com (Suravee Suthikulanit)
Date: 2015-05-18 22:38:48
Also in: linux-acpi, linux-crypto, lkml, netdev

Hi Rafael,

On 5/15/2015 6:53 PM, Rafael J. Wysocki wrote:
On Friday, May 15, 2015 04:23:09 PM Suravee Suthikulpanit wrote:
quoted
[...]
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 4bf7559..f6bc438 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -103,14 +103,18 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
  	pdevinfo.res = resources;
  	pdevinfo.num_res = count;
  	pdevinfo.fwnode = acpi_fwnode_handle(adev);
-	pdevinfo.dma_mask = DMA_BIT_MASK(32);
+	pdevinfo.dma_mask = acpi_dma_is_supported(adev) ? DMA_BIT_MASK(32) : 0;
  	pdev = platform_device_register_full(&pdevinfo);
-	if (IS_ERR(pdev))
+	if (IS_ERR(pdev)) {
  		dev_err(&adev->dev, "platform device creation failed: %ld\n",
  			PTR_ERR(pdev));
-	else
+	} else {
+		if (acpi_dma_is_supported(adev))
+			arch_setup_dma_ops(&pdev->dev, 0, 0, NULL,
+					   acpi_dma_is_coherent(adev));
Shouldn't we generally do that in acpi_bind_one() for all bus types
that don't have specific handling rather than here?
I think that would also work, and makes sense. However, I'm not sure if 
this would help in the case when we are creating PCI end-point devices, 
since the CCA is specified at the host bridge node, and there is no ACPI 
companion for the end-point devices. It seems that patch 3/6 of this 
series is still needed.

quoted
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 849b699..c56e66a 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,44 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp)
  	kfree(pnp->unique_id);
  }

+static void acpi_init_coherency(struct acpi_device *adev)
+{
+	unsigned long long cca = 0;
+	acpi_status status;
+	struct acpi_device *parent = adev->parent;
+	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+
+	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);
Shouldn't the device's own _CCA take precedence?
According to the ACPI specification, the parent's _CCA take precedence.
quoted
+	} else {
+		status = acpi_evaluate_integer(adev->handle, "_CCA",
+					       NULL, &cca);
+		if (ACPI_SUCCESS(status)) {
+			adev->flags.cca_seen = 1;
+		} else if (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED)) {
+			/*
+			 * If architecture does not specify that _CCA is
+			 * required for DMA-able devices (e.g. x86),
+			 * we default to _CCA=1.
+			 */
+			cca = 1;
+		} else {
What about using acpi_handle_debug() here?
Ok I can do that.
quoted
[...]
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 8de4fa9..2a05ffb 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;
I'd prefer to call this 'coherent_dma'.
OK.

Thanks,

Suravee
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help