All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suravee Suthikulanit <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, arnd@arndb.de, msalter@redhat.com,
	hanjun.guo@linaro.org, al.stone@linaro.org,
	grant.likely@linaro.org, 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
Subject: Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
Date: Fri, 22 May 2015 20:38:28 -0500	[thread overview]
Message-ID: <555FDA14.9050404@amd.com> (raw)
In-Reply-To: <9319342.HPcAml3MbA@vostro.rjw.lan>

On 5/22/2015 8:25 PM, Rafael J. Wysocki wrote:
> On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
>> On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
>>> On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
>>>> Not sure if this went out earlier. So I am resending.
>>>>
>>>> On 5/22/15 16:56, Rafael J. Wysocki wrote:
>>>>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
>>>>>>> index 39c485b..b9657af 100644
>>>>>>> --- a/drivers/acpi/glue.c
>>>>>>> +++ b/drivers/acpi/glue.c
>>>>>>> @@ -13,6 +13,7 @@
>>>>>>>    #include <linux/slab.h>
>>>>>>>    #include <linux/rwsem.h>
>>>>>>>    #include <linux/acpi.h>
>>>>>>> +#include <linux/dma-mapping.h>
>>>>>>>
>>>>>>>    #include "internal.h"
>>>>>>>
>>>>>>> @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>>>>>>>    	struct list_head *physnode_list;
>>>>>>>    	unsigned int node_id;
>>>>>>>    	int retval = -EINVAL;
>>>>>>> +	bool coherent;
>>>>>>>
>>>>>>>    	if (has_acpi_companion(dev)) {
>>>>>>>    		if (acpi_dev) {
>>>>>>> @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>>>>>>>    	if (!has_acpi_companion(dev))
>>>>>>>    		ACPI_COMPANION_SET(dev, acpi_dev);
>>>>>>>
>>>>>>> +	if (acpi_check_dma(acpi_dev, &coherent))
>>>>>>> +		arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
>>>>>>> +
>>>>> Well, so is this going to work for PCI too after all?
>>>>>
>>>>
>>>> No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA
>>>> (patch 3/6 in V4) will be submitted separately. We are working on
>>>> cleaning up and up-streaming the PCI ACPI support for ARM64.
>>>
>>> OK, but acpi_bind_one() is called for PCI devices too.  Won't that be a problem?
>>>
>>>
>>   >
>> In this case, we would be going through the following call path:
>>
>>     --> pci_device_add()
>>      |--> pci_dma_configure() ** 1 **
>>      |--> device_add()
>>        |--> platform_notify()
>>          |--> acpi_platform_notify()
>>           |--> acpi_bind_one() ** 2 **
>>
>> At (1), we would be calling arch_setup_dma_ops() with the PCI host
>> bridge _CCA information. So, it should have already taken care of
>> setting up device coherency here.
>>
>> At (2), if there is no acpi_dev for endpoint devices (which I believe
>> this is normally the case), it would return early and skip
>> arch_setup_dma_ops().
>
> That's not correct.  There may be ACPI companions for endpoint devices too.

Ok. Duly noted :)

>> At (2), if there is an acpi_dev, the coherent_dma flag should have
>> already been setup by the acpi_init_device_object during ACPI scan.
>
> That one sets the flag for the *ACPI* *companion* of the device, which
> I'm still thinking is pointless, isn't it?

When you say pointless, are you referring to the part where we are end 
up calling arch_setup_dma_coherent() twice in this case? I am not quite 
following your point.

>> However, I am not certain about this case since I don't have the DSDT
>> containing  PCI endpoint devices to test with.
>
> Every x86 PC has them (as far as I can say), but in that case there's no
> _CCA and they are all coherent.

Ok.

Thanks,
Suravee



WARNING: multiple messages have this Message-ID (diff)
From: Suravee Suthikulanit <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>,
	<arnd@arndb.de>, <msalter@redhat.com>, <hanjun.guo@linaro.org>,
	<al.stone@linaro.org>, <grant.likely@linaro.org>,
	<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>
Subject: Re: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
Date: Fri, 22 May 2015 20:38:28 -0500	[thread overview]
Message-ID: <555FDA14.9050404@amd.com> (raw)
In-Reply-To: <9319342.HPcAml3MbA@vostro.rjw.lan>

On 5/22/2015 8:25 PM, Rafael J. Wysocki wrote:
> On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
>> On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
>>> On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
>>>> Not sure if this went out earlier. So I am resending.
>>>>
>>>> On 5/22/15 16:56, Rafael J. Wysocki wrote:
>>>>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
>>>>>>> index 39c485b..b9657af 100644
>>>>>>> --- a/drivers/acpi/glue.c
>>>>>>> +++ b/drivers/acpi/glue.c
>>>>>>> @@ -13,6 +13,7 @@
>>>>>>>    #include <linux/slab.h>
>>>>>>>    #include <linux/rwsem.h>
>>>>>>>    #include <linux/acpi.h>
>>>>>>> +#include <linux/dma-mapping.h>
>>>>>>>
>>>>>>>    #include "internal.h"
>>>>>>>
>>>>>>> @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>>>>>>>    	struct list_head *physnode_list;
>>>>>>>    	unsigned int node_id;
>>>>>>>    	int retval = -EINVAL;
>>>>>>> +	bool coherent;
>>>>>>>
>>>>>>>    	if (has_acpi_companion(dev)) {
>>>>>>>    		if (acpi_dev) {
>>>>>>> @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>>>>>>>    	if (!has_acpi_companion(dev))
>>>>>>>    		ACPI_COMPANION_SET(dev, acpi_dev);
>>>>>>>
>>>>>>> +	if (acpi_check_dma(acpi_dev, &coherent))
>>>>>>> +		arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
>>>>>>> +
>>>>> Well, so is this going to work for PCI too after all?
>>>>>
>>>>
>>>> No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA
>>>> (patch 3/6 in V4) will be submitted separately. We are working on
>>>> cleaning up and up-streaming the PCI ACPI support for ARM64.
>>>
>>> OK, but acpi_bind_one() is called for PCI devices too.  Won't that be a problem?
>>>
>>>
>>   >
>> In this case, we would be going through the following call path:
>>
>>     --> pci_device_add()
>>      |--> pci_dma_configure() ** 1 **
>>      |--> device_add()
>>        |--> platform_notify()
>>          |--> acpi_platform_notify()
>>           |--> acpi_bind_one() ** 2 **
>>
>> At (1), we would be calling arch_setup_dma_ops() with the PCI host
>> bridge _CCA information. So, it should have already taken care of
>> setting up device coherency here.
>>
>> At (2), if there is no acpi_dev for endpoint devices (which I believe
>> this is normally the case), it would return early and skip
>> arch_setup_dma_ops().
>
> That's not correct.  There may be ACPI companions for endpoint devices too.

Ok. Duly noted :)

>> At (2), if there is an acpi_dev, the coherent_dma flag should have
>> already been setup by the acpi_init_device_object during ACPI scan.
>
> That one sets the flag for the *ACPI* *companion* of the device, which
> I'm still thinking is pointless, isn't it?

When you say pointless, are you referring to the part where we are end 
up calling arch_setup_dma_coherent() twice in this case? I am not quite 
following your point.

>> However, I am not certain about this case since I don't have the DSDT
>> containing  PCI endpoint devices to test with.
>
> Every x86 PC has them (as far as I can say), but in that case there's no
> _CCA and they are all coherent.

Ok.

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: [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency
Date: Fri, 22 May 2015 20:38:28 -0500	[thread overview]
Message-ID: <555FDA14.9050404@amd.com> (raw)
In-Reply-To: <9319342.HPcAml3MbA@vostro.rjw.lan>

On 5/22/2015 8:25 PM, Rafael J. Wysocki wrote:
> On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
>> On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
>>> On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
>>>> Not sure if this went out earlier. So I am resending.
>>>>
>>>> On 5/22/15 16:56, Rafael J. Wysocki wrote:
>>>>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
>>>>>>> index 39c485b..b9657af 100644
>>>>>>> --- a/drivers/acpi/glue.c
>>>>>>> +++ b/drivers/acpi/glue.c
>>>>>>> @@ -13,6 +13,7 @@
>>>>>>>    #include <linux/slab.h>
>>>>>>>    #include <linux/rwsem.h>
>>>>>>>    #include <linux/acpi.h>
>>>>>>> +#include <linux/dma-mapping.h>
>>>>>>>
>>>>>>>    #include "internal.h"
>>>>>>>
>>>>>>> @@ -167,6 +168,7 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>>>>>>>    	struct list_head *physnode_list;
>>>>>>>    	unsigned int node_id;
>>>>>>>    	int retval = -EINVAL;
>>>>>>> +	bool coherent;
>>>>>>>
>>>>>>>    	if (has_acpi_companion(dev)) {
>>>>>>>    		if (acpi_dev) {
>>>>>>> @@ -223,6 +225,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>>>>>>>    	if (!has_acpi_companion(dev))
>>>>>>>    		ACPI_COMPANION_SET(dev, acpi_dev);
>>>>>>>
>>>>>>> +	if (acpi_check_dma(acpi_dev, &coherent))
>>>>>>> +		arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
>>>>>>> +
>>>>> Well, so is this going to work for PCI too after all?
>>>>>
>>>>
>>>> No, as Bjorn suggested, PCI changes for setting DMA coherent from _CCA
>>>> (patch 3/6 in V4) will be submitted separately. We are working on
>>>> cleaning up and up-streaming the PCI ACPI support for ARM64.
>>>
>>> OK, but acpi_bind_one() is called for PCI devices too.  Won't that be a problem?
>>>
>>>
>>   >
>> In this case, we would be going through the following call path:
>>
>>     --> pci_device_add()
>>      |--> pci_dma_configure() ** 1 **
>>      |--> device_add()
>>        |--> platform_notify()
>>          |--> acpi_platform_notify()
>>           |--> acpi_bind_one() ** 2 **
>>
>> At (1), we would be calling arch_setup_dma_ops() with the PCI host
>> bridge _CCA information. So, it should have already taken care of
>> setting up device coherency here.
>>
>> At (2), if there is no acpi_dev for endpoint devices (which I believe
>> this is normally the case), it would return early and skip
>> arch_setup_dma_ops().
>
> That's not correct.  There may be ACPI companions for endpoint devices too.

Ok. Duly noted :)

>> At (2), if there is an acpi_dev, the coherent_dma flag should have
>> already been setup by the acpi_init_device_object during ACPI scan.
>
> That one sets the flag for the *ACPI* *companion* of the device, which
> I'm still thinking is pointless, isn't it?

When you say pointless, are you referring to the part where we are end 
up calling arch_setup_dma_coherent() twice in this case? I am not quite 
following your point.

>> However, I am not certain about this case since I don't have the DSDT
>> containing  PCI endpoint devices to test with.
>
> Every x86 PC has them (as far as I can say), but in that case there's no
> _CCA and they are all coherent.

Ok.

Thanks,
Suravee

  reply	other threads:[~2015-05-23  1:38 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 22:09 [V5 PATCH 0/5] ACPI: Introduce support for _CCA object Suravee Suthikulpanit
2015-05-20 22:09 ` Suravee Suthikulpanit
2015-05-20 22:09 ` Suravee Suthikulpanit
2015-05-20 22:09 ` [V5 PATCH 1/5] ACPI / scan: Parse _CCA and setup device coherency Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-22 21:56   ` Rafael J. Wysocki
2015-05-22 21:56     ` Rafael J. Wysocki
2015-05-22 22:24     ` Suravee Suthikulanit
2015-05-22 22:24       ` Suravee Suthikulanit
2015-05-22 22:24       ` Suravee Suthikulanit
2015-05-22 23:05       ` Rafael J. Wysocki
2015-05-22 23:05         ` Rafael J. Wysocki
2015-05-23  0:15         ` Suravee Suthikulanit
2015-05-23  0:15           ` Suravee Suthikulanit
2015-05-23  0:15           ` Suravee Suthikulanit
2015-05-23  1:25           ` Rafael J. Wysocki
2015-05-23  1:25             ` Rafael J. Wysocki
2015-05-23  1:38             ` Suravee Suthikulanit [this message]
2015-05-23  1:38               ` Suravee Suthikulanit
2015-05-23  1:38               ` Suravee Suthikulanit
2015-05-20 22:09 ` [V5 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-29  2:38   ` Mark Salter
2015-05-29  2:38     ` Mark Salter
2015-06-03 14:37     ` Suravee Suthikulanit
2015-06-03 14:37       ` Suravee Suthikulanit
2015-06-03 14:37       ` Suravee Suthikulanit
2015-06-03 15:03       ` Mark Salter
2015-06-03 15:03         ` Mark Salter
2015-05-20 22:09 ` [V5 PATCH 3/5] device property: Introduces device_dma_is_coherent() Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-20 22:09 ` [V5 PATCH 4/5] crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-20 22:09 ` [V5 PATCH 5/5] amd-xgbe: " Suravee Suthikulpanit
2015-05-20 22:09   ` Suravee Suthikulpanit
2015-05-20 22:09   ` 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=555FDA14.9050404@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.