From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: thomas.lendacky@amd.com, linux-crypto@vger.kernel.org,
herbert@gondor.apana.org.au, arnd@arndb.de,
linaro-acpi@lists.linaro.org, will.deacon@arm.com,
linux-kernel@vger.kernel.org, al.stone@linaro.org,
linux-acpi@vger.kernel.org, netdev@vger.kernel.org,
leo.duran@amd.com, hanjun.guo@linaro.org, msalter@redhat.com,
grant.likely@linaro.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org, lenb@kernel.org
Subject: Re: [V3 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
Date: Tue, 12 May 2015 10:06:01 -0500 [thread overview]
Message-ID: <555216D9.30506@amd.com> (raw)
In-Reply-To: <1664523.WMm4AqWTY5@vostro.rjw.lan>
On 5/11/2015 8:20 PM, Rafael J. Wysocki wrote:
> On Monday, May 11, 2015 05:16:27 PM Catalin Marinas wrote:
>> On Fri, May 08, 2015 at 10:53:59PM +0200, Rafael J. Wysocki wrote:
>>> On Thursday, May 07, 2015 07:37:12 PM Suravee Suthikulpanit wrote:
>>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>>> index ab2cbb5..7822149 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_CCA_REQUIRED
>>>> + bool
>>>> +
>>>> +config ARM64_SUPPORT_ACPI_CCA_ZERO
>>>
>>> Hmm. I guess the Arnd's idea what to simply use CONFIG_ARM64 directly instead
>>> of adding this new option.
>>
>> I agree.
>>
>>>> +static inline bool acpi_dma_is_supported(struct acpi_device *adev)
>>>> +{
>>>> + /**
>>>> + * Currently, we mainly support _CCA=1 (i.e. is_coherent=1)
>>>> + * This should be equivalent to specifyig dma-coherent for
>>>> + * a device in OF.
>>>> + *
>>>> + * 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 specifies
>>>> + * _XXX_SUPPORT_CCA_ZERO. Otherwise, we do not support
>>>> + * DMA on this device and fallback to arch-specific default
>>>> + * handling.
>>>> + *
>>>> + * For the case when _CCA is missing (i.e. cca_seen=0) but
>>>> + * platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
>>>> + * and fallback to arch-specific default handling.
>>>> + */
>>>> + return adev && (adev->flags.is_coherent ||
>>>> + (adev->flags.cca_seen &&
>>>> + IS_ENABLED(CONFIG_ARM64_SUPPORT_ACPI_CCA_ZERO)));
>>>
>>> So what exactly would be wrong with using IS_ENABLED(CONFIG_ARM64) here?
>>
>> I'm not sure I follow why we need to check for ARM64 here at all. Can we
>> not just have something like:
>>
>> return adev && (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED) ||
>> adev->flags.cca_seen)
>
> If _CCA returns 0 on non-ARM64, DMA is not supported for this device, so
> in that case the function should return 'false' while the above check will
> make it return 'true'.
>
The main idea is basically to allow architecture to decide if it wants
to specify if it wants to support _CCA=0. Currently, there are two
approaches.
1. Do not support and disable DMA
2. Support and default to what architecture would normally do for
non-coherent DMA.
Since, ARM64 being the only platform, which supports ACPI and would
support _CCA=0. I can just put CONFIG_ARM64 then as Arnd and Rafael
mentioned.
Thanks,
Suravee
WARNING: multiple messages have this Message-ID (diff)
From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: <thomas.lendacky@amd.com>, <linux-crypto@vger.kernel.org>,
<herbert@gondor.apana.org.au>, <arnd@arndb.de>,
<linaro-acpi@lists.linaro.org>, <will.deacon@arm.com>,
<linux-kernel@vger.kernel.org>, <al.stone@linaro.org>,
<linux-acpi@vger.kernel.org>, <netdev@vger.kernel.org>,
<leo.duran@amd.com>, <hanjun.guo@linaro.org>,
<msalter@redhat.com>, <grant.likely@linaro.org>,
<davem@davemloft.net>, <linux-arm-kernel@lists.infradead.org>,
<lenb@kernel.org>
Subject: Re: [V3 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
Date: Tue, 12 May 2015 10:06:01 -0500 [thread overview]
Message-ID: <555216D9.30506@amd.com> (raw)
In-Reply-To: <1664523.WMm4AqWTY5@vostro.rjw.lan>
On 5/11/2015 8:20 PM, Rafael J. Wysocki wrote:
> On Monday, May 11, 2015 05:16:27 PM Catalin Marinas wrote:
>> On Fri, May 08, 2015 at 10:53:59PM +0200, Rafael J. Wysocki wrote:
>>> On Thursday, May 07, 2015 07:37:12 PM Suravee Suthikulpanit wrote:
>>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>>> index ab2cbb5..7822149 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_CCA_REQUIRED
>>>> + bool
>>>> +
>>>> +config ARM64_SUPPORT_ACPI_CCA_ZERO
>>>
>>> Hmm. I guess the Arnd's idea what to simply use CONFIG_ARM64 directly instead
>>> of adding this new option.
>>
>> I agree.
>>
>>>> +static inline bool acpi_dma_is_supported(struct acpi_device *adev)
>>>> +{
>>>> + /**
>>>> + * Currently, we mainly support _CCA=1 (i.e. is_coherent=1)
>>>> + * This should be equivalent to specifyig dma-coherent for
>>>> + * a device in OF.
>>>> + *
>>>> + * 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 specifies
>>>> + * _XXX_SUPPORT_CCA_ZERO. Otherwise, we do not support
>>>> + * DMA on this device and fallback to arch-specific default
>>>> + * handling.
>>>> + *
>>>> + * For the case when _CCA is missing (i.e. cca_seen=0) but
>>>> + * platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
>>>> + * and fallback to arch-specific default handling.
>>>> + */
>>>> + return adev && (adev->flags.is_coherent ||
>>>> + (adev->flags.cca_seen &&
>>>> + IS_ENABLED(CONFIG_ARM64_SUPPORT_ACPI_CCA_ZERO)));
>>>
>>> So what exactly would be wrong with using IS_ENABLED(CONFIG_ARM64) here?
>>
>> I'm not sure I follow why we need to check for ARM64 here at all. Can we
>> not just have something like:
>>
>> return adev && (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED) ||
>> adev->flags.cca_seen)
>
> If _CCA returns 0 on non-ARM64, DMA is not supported for this device, so
> in that case the function should return 'false' while the above check will
> make it return 'true'.
>
The main idea is basically to allow architecture to decide if it wants
to specify if it wants to support _CCA=0. Currently, there are two
approaches.
1. Do not support and disable DMA
2. Support and default to what architecture would normally do for
non-coherent DMA.
Since, ARM64 being the only platform, which supports ACPI and would
support _CCA=0. I can just put CONFIG_ARM64 then as Arnd and Rafael
mentioned.
Thanks,
Suravee
WARNING: multiple messages have this Message-ID (diff)
From: suravee.suthikulpanit@amd.com (Suravee Suthikulanit)
To: linux-arm-kernel@lists.infradead.org
Subject: [V3 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
Date: Tue, 12 May 2015 10:06:01 -0500 [thread overview]
Message-ID: <555216D9.30506@amd.com> (raw)
In-Reply-To: <1664523.WMm4AqWTY5@vostro.rjw.lan>
On 5/11/2015 8:20 PM, Rafael J. Wysocki wrote:
> On Monday, May 11, 2015 05:16:27 PM Catalin Marinas wrote:
>> On Fri, May 08, 2015 at 10:53:59PM +0200, Rafael J. Wysocki wrote:
>>> On Thursday, May 07, 2015 07:37:12 PM Suravee Suthikulpanit wrote:
>>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>>> index ab2cbb5..7822149 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_CCA_REQUIRED
>>>> + bool
>>>> +
>>>> +config ARM64_SUPPORT_ACPI_CCA_ZERO
>>>
>>> Hmm. I guess the Arnd's idea what to simply use CONFIG_ARM64 directly instead
>>> of adding this new option.
>>
>> I agree.
>>
>>>> +static inline bool acpi_dma_is_supported(struct acpi_device *adev)
>>>> +{
>>>> + /**
>>>> + * Currently, we mainly support _CCA=1 (i.e. is_coherent=1)
>>>> + * This should be equivalent to specifyig dma-coherent for
>>>> + * a device in OF.
>>>> + *
>>>> + * 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 specifies
>>>> + * _XXX_SUPPORT_CCA_ZERO. Otherwise, we do not support
>>>> + * DMA on this device and fallback to arch-specific default
>>>> + * handling.
>>>> + *
>>>> + * For the case when _CCA is missing (i.e. cca_seen=0) but
>>>> + * platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
>>>> + * and fallback to arch-specific default handling.
>>>> + */
>>>> + return adev && (adev->flags.is_coherent ||
>>>> + (adev->flags.cca_seen &&
>>>> + IS_ENABLED(CONFIG_ARM64_SUPPORT_ACPI_CCA_ZERO)));
>>>
>>> So what exactly would be wrong with using IS_ENABLED(CONFIG_ARM64) here?
>>
>> I'm not sure I follow why we need to check for ARM64 here at all. Can we
>> not just have something like:
>>
>> return adev && (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED) ||
>> adev->flags.cca_seen)
>
> If _CCA returns 0 on non-ARM64, DMA is not supported for this device, so
> in that case the function should return 'false' while the above check will
> make it return 'true'.
>
The main idea is basically to allow architecture to decide if it wants
to specify if it wants to support _CCA=0. Currently, there are two
approaches.
1. Do not support and disable DMA
2. Support and default to what architecture would normally do for
non-coherent DMA.
Since, ARM64 being the only platform, which supports ACPI and would
support _CCA=0. I can just put CONFIG_ARM64 then as Arnd and Rafael
mentioned.
Thanks,
Suravee
next prev parent reply other threads:[~2015-05-12 15:06 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 0:37 [V3 PATCH 0/5] ACPI: Introduce support for _CCA object Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` [V3 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 20:53 ` Rafael J. Wysocki
2015-05-08 20:53 ` Rafael J. Wysocki
2015-05-11 16:16 ` Catalin Marinas
2015-05-11 16:16 ` Catalin Marinas
2015-05-12 1:20 ` Rafael J. Wysocki
2015-05-12 1:20 ` Rafael J. Wysocki
2015-05-12 15:06 ` Suravee Suthikulanit [this message]
2015-05-12 15:06 ` Suravee Suthikulanit
2015-05-12 15:06 ` Suravee Suthikulanit
2015-05-08 0:37 ` [V3 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 20:55 ` Rafael J. Wysocki
2015-05-08 20:55 ` Rafael J. Wysocki
2015-05-11 17:12 ` Catalin Marinas
2015-05-11 17:12 ` Catalin Marinas
2015-05-08 0:37 ` [V3 PATCH 3/5] device property: Introduces device_dma_is_coherent() Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 4:12 ` santosh.shilimkar
2015-05-08 4:12 ` santosh.shilimkar at oracle.com
2015-05-08 20:49 ` Rafael J. Wysocki
2015-05-08 20:49 ` Rafael J. Wysocki
2015-05-08 20:27 ` santosh shilimkar
2015-05-08 20:27 ` santosh shilimkar
2015-05-08 20:58 ` Rafael J. Wysocki
2015-05-08 20:58 ` Rafael J. Wysocki
2015-05-08 20:36 ` santosh shilimkar
2015-05-08 20:36 ` santosh shilimkar
2015-05-08 0:37 ` [V3 PATCH 4/5] crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` [V3 PATCH 5/5] amd-xgbe: " Suravee Suthikulpanit
2015-05-08 0:37 ` Suravee Suthikulpanit
2015-05-08 0:37 ` 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=555216D9.30506@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=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 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.