From patchwork Tue Dec 6 08:40:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aleksey Makarov X-Patchwork-Id: 86709 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp1905401qgi; Tue, 6 Dec 2016 00:41:17 -0800 (PST) X-Received: by 10.84.202.12 with SMTP id w12mr135503667pld.156.1481013677816; Tue, 06 Dec 2016 00:41:17 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r20si18657675pfj.47.2016.12.06.00.41.17; Tue, 06 Dec 2016 00:41:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753029AbcLFIlA (ORCPT + 7 others); Tue, 6 Dec 2016 03:41:00 -0500 Received: from mail-lf0-f50.google.com ([209.85.215.50]:34783 "EHLO mail-lf0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752961AbcLFIk5 (ORCPT ); Tue, 6 Dec 2016 03:40:57 -0500 Received: by mail-lf0-f50.google.com with SMTP id o141so240103407lff.1 for ; Tue, 06 Dec 2016 00:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YxPUDkhZOFT53qibLCa0zZJzgTaFzLnpl8xSfaSGb9U=; b=DhP8DinXuMbbP5mCKhCG2VNDpNC4SNpFgd4YZMGeu9NMMj/91Fnlz4ysWpZMz1gqEo 4bcYwIlmyaRUpbRd/OPMbqhEvB31z2w4xWiicUmM1/Vy9VUXvo57EpdIR9wg6Yde6IrE jEmmil3ZCLmedjQYCXWp6WxPh4IZ/Y1zjEWi4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YxPUDkhZOFT53qibLCa0zZJzgTaFzLnpl8xSfaSGb9U=; b=OQV3nH1R/p9CSRHv2gsMbKBCQw+vjamCgcSdJaKE7/SXzuVFPmQhDWmdVdoqqzrOtu WdaM5fS3yXvIxjgRwZYgbVoH29vI/fvnus8I+rhclleMjJTx9J1GX5Wm21sdsx9gaNVl OpN11SFj/OScxgI+buxe0J7kmjmpRVjOh9zQuXNd2S7eJeY9mcOC0XYSypWI5h7sQ5/i HIr2FyfjJoytT120tAQzal5LdyjE7X70EvTtR/KIvuDEJuXmDz1mCIHt7og19xksUztN 1hFuG1PWTeS+fOurd0gcAqribPmSgwHlBxH5nbZcfJ7VyLdcWr4OInXMI/xpjLGPSosa 0NgQ== X-Gm-Message-State: AKaTC019ibxfwm1WeeS5rb+zbVbh73qvq+v5qBs73jhE732o4of2qxgweQ6cHilUaSbp0kxA X-Received: by 10.25.66.214 with SMTP id p205mr15874508lfa.102.1481013655679; Tue, 06 Dec 2016 00:40:55 -0800 (PST) Received: from [192.168.0.4] (host-95-189-166-46.pppoe.omsknet.ru. [95.189.166.46]) by smtp.gmail.com with ESMTPSA id t126sm3716872lff.26.2016.12.06.00.40.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 00:40:54 -0800 (PST) Subject: Re: [PATCH] SPCR: check bit width for the 16550 UART To: Jon Masters , Duc Dang References: <20161205130534.11080-1-aleksey.makarov@linaro.org> <3a6193ef-ca86-c113-b09a-5d6c882137e2@redhat.com> <53421849-d031-77e1-9edb-53c9d673d462@redhat.com> <966938c5-4540-593d-e763-18cf879b325d@redhat.com> <0b8324fe-e564-226a-94b1-8ed2946db3d1@redhat.com> Cc: "Rafael J . Wysocki" , linux-acpi@vger.kernel.org, linux-serial@vger.kernel.org, Linux Kernel Mailing List , Greg Kroah-Hartman , Russell King , Peter Hurley , Mark Salter , Graeme Gregory , Len Brown , Rob Herring From: Aleksey Makarov Message-ID: Date: Tue, 6 Dec 2016 14:40:52 +0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <0b8324fe-e564-226a-94b1-8ed2946db3d1@redhat.com> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi Jon, On 12/06/2016 01:13 PM, Jon Masters wrote: > On 12/06/2016 01:53 AM, Jon Masters wrote: >> On 12/06/2016 01:34 AM, Jon Masters wrote: >>> On 12/05/2016 10:55 PM, Duc Dang wrote: >>>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters wrote: > >> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */, >> Package (0x01) >> { >> Package (0x02) >> { >> "clock-frequency", >> Zero >> } >> } > >> I suspect Mustang is doing similar. So you read the magic frequency > ^^^^^^^^^^^^^ > spoiler, it is :) > >> info and pass this in through a DSD in the AML. It's ok, I've made my >> peace with this (but obviously we're trying to kill all DSD hacks), >> but it explains how this "works" after boot, but not for early console. >> >> To fix this, we're going to need to be able to know that your 8250 is >> both needful of 32-bit accesses *AND* needs a different base UART clock. >> Fortunately our good friends at Microsoft are amenable to adding a >> subtype that covers this and are going to followup tomorrow for me. > > For the earlycon setup, you'll probably benefit from figuring out > ahead of time how you'll want to handle this. The "easy" option > is to remove the baud in the case of X-Gene with new subtype > but that'll be potential fragile. You might also decide that > struct earlycon_device wants to grow a "quirks" flag that > you can set for this kind of thing (bound to be more). I don't see why new subtypes or quirk flags are required. My suggestion is to change SPCR spec so that - Access width should be specified by the "Bit width" subfield of the "Base address" field. When "Interface type" is ACPI_DBG2_ARM_SBSA_32BIT, disregard this value and use mmio32 (legacy case) - Add a new value 0 (now it is reserved) for "Baud rate" field with meaning "do not change pre-initialized clock rate" Then spcr.c should be fixed this way: ------------------------------ All the best Aleksey Makarov > Copying Rob as well in case he has suggestions for you. Rob, as > an FYI the AppliedMicro X-Gene 16550 "compatible" requires both > 32-bit accesses (which Aleksey tried to address earlier in this > thread) but also has a special non-standard clock (to be fair, > it's not as if we architected a standard UART clock for arm64, > we just assumed it was like x86 but didn't mandate this early > when Applied were doing their design - another life lesson). > Microsoft will add a new DBG2 subtype that allows for both > of these situations. But you'll want to somehow convey this > information (quirks) in one of the earlycon structures. > > Jon. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c index 6c6710b..9c6c0b4 100644 --- a/drivers/acpi/spcr.c +++ b/drivers/acpi/spcr.c @@ -37,7 +37,7 @@ int __init parse_spcr(bool earlycon) acpi_status status; char *uart; char *iotype; - int baud_rate; + char *baud_rate_string; int err; if (acpi_disabled) @@ -56,13 +56,19 @@ int __init parse_spcr(bool earlycon) goto done; } - iotype = table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY ? - "mmio" : "io"; + if (table->interface_type == ACPI_DBG2_ARM_SBSA_32BIT) { + iotype = "mmio32"; + } else if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) { + if (table->serial_port.bit_width == 32) + iotype = "mmio32"; + else + iotype = "mmio"; + } else { + iotype = "io"; + } switch (table->interface_type) { case ACPI_DBG2_ARM_SBSA_32BIT: - iotype = "mmio32"; - /* fall through */ case ACPI_DBG2_ARM_PL011: case ACPI_DBG2_ARM_SBSA_GENERIC: case ACPI_DBG2_BCM2835: @@ -70,10 +76,6 @@ int __init parse_spcr(bool earlycon) break; case ACPI_DBG2_16550_COMPATIBLE: case ACPI_DBG2_16550_SUBSET: - if (table->serial_port.space_id == - ACPI_ADR_SPACE_SYSTEM_MEMORY && - table->serial_port.bit_width == 32) - iotype = "mmio32"; uart = "uart"; break; default: @@ -82,25 +84,33 @@ int __init parse_spcr(bool earlycon) } switch (table->baud_rate) { + case 0: + /* + * This value is not standaritzed by ACPI SPCR for now. + * It means that hardware should not be re-initialized with + * new speed. + */ + baud_rate_string = ""; + break; case 3: - baud_rate = 9600; + baud_rate_string = ",9600"; break; case 4: - baud_rate = 19200; + baud_rate_string = ",19200"; break; case 6: - baud_rate = 57600; + baud_rate_string = ",57600"; break; case 7: - baud_rate = 115200; + baud_rate_string = ",115200"; break; default: err = -ENOENT; goto done; } - snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype, - table->serial_port.address, baud_rate); + snprintf(opts, sizeof(opts), "%s,%s,0x%llx%s", uart, iotype, + table->serial_port.address, baud_rate_string); pr_info("console: %s\n", opts);