From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: <lenb@kernel.org>, <catalin.marinas@arm.com>,
<will.deacon@arm.com>, <thomas.lendacky@amd.com>,
<herbert@gondor.apana.org.au>, <davem@davemloft.net>,
<msalter@redhat.com>, <hanjun.guo@linaro.org>,
<al.stone@linaro.org>, <grant.likely@linaro.org>, <arnd@arndb.de>,
<leo.duran@amd.com>, <linux-arm-kernel@lists.infradead.org>,
<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linaro-acpi@lists.linaro.org>, <netdev@vger.kernel.org>,
<linux-crypto@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
Date: Tue, 5 May 2015 23:15:37 -0500 [thread overview]
Message-ID: <55499569.8060403@amd.com> (raw)
In-Reply-To: <3234610.3j3NfP3xpR@vostro.rjw.lan>
[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
next prev parent reply other threads:[~2015-05-06 4:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` [V2 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency Suravee Suthikulpanit
2015-05-05 20:36 ` Rafael J. Wysocki
2015-05-06 4:15 ` Suravee Suthikulpanit [this message]
2015-05-06 22:21 ` Rafael J. Wysocki
2015-05-06 22:16 ` Suravee Suthikulanit
2015-05-07 9:07 ` [Linaro-acpi] " Arnd Bergmann
2015-05-07 20:18 ` Rafael J. Wysocki
2015-05-06 3:13 ` Hanjun Guo
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:44 ` Arnd Bergmann
2015-05-05 16:09 ` Suravee Suthikulanit
2015-05-05 16:12 ` [Linaro-acpi] " Arnd Bergmann
2015-05-05 16:13 ` Suravee Suthikulanit
2015-05-05 16:24 ` Tom Lendacky
2015-05-05 18:02 ` Arnd Bergmann
2015-05-06 10:08 ` Robin Murphy
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-06 23:52 ` Suravee Suthikulanit
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 ` [V2 PATCH 5/5] amd-xgbe: " Suravee Suthikulpanit
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=55499569.8060403@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=al.stone@linaro.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=herbert@gondor.apana.org.au \
--cc=lenb@kernel.org \
--cc=leo.duran@amd.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=msalter@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=thomas.lendacky@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).