All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>,
	rjw@rjwysocki.net, mika.westerberg@linux.intel.com,
	robert.moore@intel.com, lv.zheng@intel.com, lenb@kernel.org,
	hanjun.guo@linaro.org
Cc: catalin.marinas@arm.com, will.deacon@arm.com,
	al.stone@linaro.org, msalter@redhat.com,
	gregkh@linuxfoundation.org, leo.duran@amd.com, arnd@arndb.de,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linaro-acpi@lists.linaro.org
Subject: Re: [RFC PATCH] ACPI / scan: Introduce _CCA parsing logic and setting up device coherency
Date: Wed, 1 Apr 2015 12:45:59 -0500	[thread overview]
Message-ID: <551C2ED7.5060507@amd.com> (raw)
In-Reply-To: <1427901620-2194-1-git-send-email-Suravee.Suthikulpanit@amd.com>

On 04/01/2015 10:20 AM, Suravee Suthikulpanit wrote:
> ACPI v5.1 introduced _CCA object for specifying cache coherency attribute
> for devices. This patch implements a logic, which traverses device namespace
> to parse the coherency information, and calling the corresponded
> arch_setup_dma_ops().
>
> It checks the _CCA during ACPI scan, and setup coherency during acpi_device creation.
> Then, this is propagted to the platform_device when it is created at later time.
>
> CC: Mark Salter <msalter@redhat.com>
> CC: Hanjun Guo <hanjun.guo@linaro.org>
> CC: Al Stone <al.stone@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> ---
>
> NOTE:
>
> The original patch has been submitted by Mark Salter, and discussed here:
>
> * http://comments.gmane.org/gmane.linux.acpi.devel/70424
>
> One of the reveiw comment was dissusing whether we need the do/while loop for
> travesing parents of the device.  AFAIK, there are no APIs that would do upsearch
> from a particular node.  The acpi_get_handle() is the closest one, but it is using
> ACPI_NS_NO_UPSEARCH.
>
> This has been rebased and tested with:
> 	* http://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v11
> 	* [V8 PATCH 0/3] Introduce ACPI support for ahci_platform driver
> 	  (https://lkml.org/lkml/2015/3/30/729)
>
>   drivers/acpi/acpi_platform.c |  5 +++-
>   drivers/acpi/scan.c          | 56 ++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index 1284138..47e37a8 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -108,9 +108,12 @@ 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 {
> +		arch_setup_dma_ops(&pdev->dev, 0, 0, NULL,
> +				   is_device_dma_coherent(&adev->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 230ec983..4d81c55 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>
>
> @@ -57,6 +58,9 @@ struct acpi_device_bus_id{
>   	struct list_head node;
>   };
>
> +static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> +				    unsigned long long *sta);
> +
>   void acpi_scan_lock_acquire(void)
>   {
>   	mutex_lock(&acpi_scan_lock);
> @@ -1327,6 +1331,51 @@ void acpi_bus_put_acpi_device(struct acpi_device *adev)
>   	put_device(&adev->dev);
>   }
>
> +/**
> + * acpi_check_and_set_coherency - check and set cache coherency of a device
> + * @device: ACPI device
> + *
> + * Search a device and its parents for a _CCA method and calculate
> + * the effective coherency property of the device. If found, set up
> + * appropriate dma_ops for the device.
> + *
> + * Note From ACPIv5.1 spec:
> + * If used _CCA must be included under all bus-master-capable
> + * devices defined as children of \_SB. The value of _CCA is inherited
> + * by all descendants of these devices, so it need not be repeated for
> + * their children devices and will be ignored by OSPM if it is provided
> + * there.
> + */
> +static int acpi_check_and_set_coherency(struct acpi_device *device)
> +{
> +	acpi_status status;
> +	unsigned long long eff_cca = ~0ULL;
> +	acpi_handle tmp, handle = device->handle;
> +
> +	/* Calculate effective _CCA from all parents of this device */
> +	do {
> +		unsigned long cca;
> +
> +		status = acpi_get_handle(handle, "_CCA", &tmp);
> +		if (ACPI_SUCCESS(status)) {
> +			status = acpi_evaluate_integer(tmp, "_CCA", NULL, &cca);
> +			/* Other values besides 0 and 1 are reserved */
> +			if (ACPI_FAILURE(status) || (cca != 0 && cca != 1))
> +				return -EINVAL;
> +			eff_cca = cca;
> +		}
> +
> +		status = acpi_get_parent(handle, &handle);
> +		if (ACPI_FAILURE(status))
> +			break;
> +	} while (ACPI_SUCCESS(status));

Having the above portion/loop be a separate function that could be
callable by others (such as drivers) would be good so that both the
ACPI code and the driver code look for the _CCA attribute the same
way - similar to the of_dma_is_coherent function.

Possibly even work this into a a generic call like the device property
functions (even though this doesn't fall into the _DSD area for ACPI) -
where for device tree the of_dma_is_coherent call is made and for ACPI
an acpi_dma_is_coherent call is made - device_dma_is_coherent?

Thanks,
Tom

> +
> +	if (eff_cca != ~0ULL)
> +		arch_setup_dma_ops(&device->dev, 0, 0, NULL, eff_cca);
> +
> +	return 0;
> +}
> +
>   int acpi_device_add(struct acpi_device *device,
>   		    void (*release)(struct device *))
>   {
> @@ -1398,6 +1447,13 @@ int acpi_device_add(struct acpi_device *device,
>   		device->dev.parent = &device->parent->dev;
>   	device->dev.bus = &acpi_bus_type;
>   	device->dev.release = release;
> +
> +	result = acpi_check_and_set_coherency(device);
> +	if (result) {
> +		dev_err(&device->dev, "Error getting device _CCA information\n");
> +		goto err;
> +	}
> +
>   	result = device_add(&device->dev);
>   	if (result) {
>   		dev_err(&device->dev, "Error registering device\n");
>

WARNING: multiple messages have this Message-ID (diff)
From: Tom Lendacky <thomas.lendacky@amd.com>
To: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>,
	<rjw@rjwysocki.net>, <mika.westerberg@linux.intel.com>,
	<robert.moore@intel.com>, <lv.zheng@intel.com>, <lenb@kernel.org>,
	<hanjun.guo@linaro.org>
Cc: <catalin.marinas@arm.com>, <will.deacon@arm.com>,
	<al.stone@linaro.org>, <msalter@redhat.com>,
	<gregkh@linuxfoundation.org>, <leo.duran@amd.com>,
	<arnd@arndb.de>, <linux-acpi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linaro-acpi@lists.linaro.org>
Subject: Re: [RFC PATCH] ACPI / scan: Introduce _CCA parsing logic and setting up device coherency
Date: Wed, 1 Apr 2015 12:45:59 -0500	[thread overview]
Message-ID: <551C2ED7.5060507@amd.com> (raw)
In-Reply-To: <1427901620-2194-1-git-send-email-Suravee.Suthikulpanit@amd.com>

On 04/01/2015 10:20 AM, Suravee Suthikulpanit wrote:
> ACPI v5.1 introduced _CCA object for specifying cache coherency attribute
> for devices. This patch implements a logic, which traverses device namespace
> to parse the coherency information, and calling the corresponded
> arch_setup_dma_ops().
>
> It checks the _CCA during ACPI scan, and setup coherency during acpi_device creation.
> Then, this is propagted to the platform_device when it is created at later time.
>
> CC: Mark Salter <msalter@redhat.com>
> CC: Hanjun Guo <hanjun.guo@linaro.org>
> CC: Al Stone <al.stone@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> ---
>
> NOTE:
>
> The original patch has been submitted by Mark Salter, and discussed here:
>
> * http://comments.gmane.org/gmane.linux.acpi.devel/70424
>
> One of the reveiw comment was dissusing whether we need the do/while loop for
> travesing parents of the device.  AFAIK, there are no APIs that would do upsearch
> from a particular node.  The acpi_get_handle() is the closest one, but it is using
> ACPI_NS_NO_UPSEARCH.
>
> This has been rebased and tested with:
> 	* http://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v11
> 	* [V8 PATCH 0/3] Introduce ACPI support for ahci_platform driver
> 	  (https://lkml.org/lkml/2015/3/30/729)
>
>   drivers/acpi/acpi_platform.c |  5 +++-
>   drivers/acpi/scan.c          | 56 ++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index 1284138..47e37a8 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -108,9 +108,12 @@ 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 {
> +		arch_setup_dma_ops(&pdev->dev, 0, 0, NULL,
> +				   is_device_dma_coherent(&adev->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 230ec983..4d81c55 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>
>
> @@ -57,6 +58,9 @@ struct acpi_device_bus_id{
>   	struct list_head node;
>   };
>
> +static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> +				    unsigned long long *sta);
> +
>   void acpi_scan_lock_acquire(void)
>   {
>   	mutex_lock(&acpi_scan_lock);
> @@ -1327,6 +1331,51 @@ void acpi_bus_put_acpi_device(struct acpi_device *adev)
>   	put_device(&adev->dev);
>   }
>
> +/**
> + * acpi_check_and_set_coherency - check and set cache coherency of a device
> + * @device: ACPI device
> + *
> + * Search a device and its parents for a _CCA method and calculate
> + * the effective coherency property of the device. If found, set up
> + * appropriate dma_ops for the device.
> + *
> + * Note From ACPIv5.1 spec:
> + * If used _CCA must be included under all bus-master-capable
> + * devices defined as children of \_SB. The value of _CCA is inherited
> + * by all descendants of these devices, so it need not be repeated for
> + * their children devices and will be ignored by OSPM if it is provided
> + * there.
> + */
> +static int acpi_check_and_set_coherency(struct acpi_device *device)
> +{
> +	acpi_status status;
> +	unsigned long long eff_cca = ~0ULL;
> +	acpi_handle tmp, handle = device->handle;
> +
> +	/* Calculate effective _CCA from all parents of this device */
> +	do {
> +		unsigned long cca;
> +
> +		status = acpi_get_handle(handle, "_CCA", &tmp);
> +		if (ACPI_SUCCESS(status)) {
> +			status = acpi_evaluate_integer(tmp, "_CCA", NULL, &cca);
> +			/* Other values besides 0 and 1 are reserved */
> +			if (ACPI_FAILURE(status) || (cca != 0 && cca != 1))
> +				return -EINVAL;
> +			eff_cca = cca;
> +		}
> +
> +		status = acpi_get_parent(handle, &handle);
> +		if (ACPI_FAILURE(status))
> +			break;
> +	} while (ACPI_SUCCESS(status));

Having the above portion/loop be a separate function that could be
callable by others (such as drivers) would be good so that both the
ACPI code and the driver code look for the _CCA attribute the same
way - similar to the of_dma_is_coherent function.

Possibly even work this into a a generic call like the device property
functions (even though this doesn't fall into the _DSD area for ACPI) -
where for device tree the of_dma_is_coherent call is made and for ACPI
an acpi_dma_is_coherent call is made - device_dma_is_coherent?

Thanks,
Tom

> +
> +	if (eff_cca != ~0ULL)
> +		arch_setup_dma_ops(&device->dev, 0, 0, NULL, eff_cca);
> +
> +	return 0;
> +}
> +
>   int acpi_device_add(struct acpi_device *device,
>   		    void (*release)(struct device *))
>   {
> @@ -1398,6 +1447,13 @@ int acpi_device_add(struct acpi_device *device,
>   		device->dev.parent = &device->parent->dev;
>   	device->dev.bus = &acpi_bus_type;
>   	device->dev.release = release;
> +
> +	result = acpi_check_and_set_coherency(device);
> +	if (result) {
> +		dev_err(&device->dev, "Error getting device _CCA information\n");
> +		goto err;
> +	}
> +
>   	result = device_add(&device->dev);
>   	if (result) {
>   		dev_err(&device->dev, "Error registering device\n");
>

  reply	other threads:[~2015-04-01 17:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 15:20 [RFC PATCH] ACPI / scan: Introduce _CCA parsing logic and setting up device coherency Suravee Suthikulpanit
2015-04-01 15:20 ` Suravee Suthikulpanit
2015-04-01 17:45 ` Tom Lendacky [this message]
2015-04-01 17:45   ` Tom Lendacky
2015-04-08 14:50 ` Mark Salter
2015-04-09 21:43 ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=551C2ED7.5060507@amd.com \
    --to=thomas.lendacky@amd.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=al.stone@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hanjun.guo@linaro.org \
    --cc=lenb@kernel.org \
    --cc=leo.duran@amd.com \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=msalter@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.