Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753250AbbDARqP (ORCPT ); Wed, 1 Apr 2015 13:46:15 -0400 Received: from mail-by2on0125.outbound.protection.outlook.com ([207.46.100.125]:53203 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752334AbbDARqL (ORCPT ); Wed, 1 Apr 2015 13:46:11 -0400 Authentication-Results: spf=none (sender IP is 165.204.84.221) smtp.mailfrom=amd.com; arm.com; dkim=none (message not signed) header.d=none; X-WSS-ID: 0NM52OT-07-KTQ-02 X-M-MSG: Message-ID: <551C2ED7.5060507@amd.com> Date: Wed, 1 Apr 2015 12:45:59 -0500 From: Tom Lendacky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Suravee Suthikulpanit , , , , , , CC: , , , , , , , , , Subject: Re: [RFC PATCH] ACPI / scan: Introduce _CCA parsing logic and setting up device coherency References: <1427901620-2194-1-git-send-email-Suravee.Suthikulpanit@amd.com> In-Reply-To: <1427901620-2194-1-git-send-email-Suravee.Suthikulpanit@amd.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.180.168.240] X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:165.204.84.221;CTRY:US;IPV:NLI;EFV:NLI;BMV:1;SFV:NSPM;SFS:(10019020)(6009001)(428002)(51704005)(164054003)(199003)(479174004)(377454003)(24454002)(189002)(2950100001)(77096005)(23746002)(50466002)(15975445007)(47776003)(19580395003)(83506001)(86362001)(80316001)(54356999)(50986999)(87266999)(76176999)(19300405004)(19580405001)(65816999)(65956001)(19273905006)(92566002)(33656002)(101416001)(64126003)(106466001)(87936001)(105586002)(46102003)(77156002)(62966003)(36756003)(562404015)(2101003)(563064011);DIR:OUT;SFP:1102;SCL:1;SRVR:DM2PR0201MB0895;H:atltwp01.amd.com;FPR:;SPF:None;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0895; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006);SRVR:DM2PR0201MB0895;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0201MB0895; X-Forefront-PRVS: 053315510E X-OriginatorOrg: amd4.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2015 17:46:07.5054 (UTC) X-MS-Exchange-CrossTenant-Id: fde4dada-be84-483f-92cc-e026cbee8e96 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fde4dada-be84-483f-92cc-e026cbee8e96;Ip=[165.204.84.221];Helo=[atltwp01.amd.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0201MB0895 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5723 Lines: 161 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 > CC: Hanjun Guo > CC: Al Stone > Signed-off-by: Suravee Suthikulpanit > --- > > 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 > #include > #include > +#include > > #include > > @@ -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"); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/