Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753029AbcLFSVB (ORCPT ); Tue, 6 Dec 2016 13:21:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38051 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751966AbcLFSUz (ORCPT ); Tue, 6 Dec 2016 13:20:55 -0500 Subject: Re: [RFC v2 0/4] ACPI: SPCR: 32-bit access and non-standard baud rate To: Aleksey Makarov , "Rafael J . Wysocki" References: <20161206175830.6989-1-aleksey.makarov@linaro.org> Cc: linux-acpi@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Russell King , Peter Hurley , Mark Salter , Duc Dang , Rob Herring From: Jon Masters Message-ID: Date: Tue, 6 Dec 2016 13:20:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20161206175830.6989-1-aleksey.makarov@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 06 Dec 2016 18:20:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1664 Lines: 39 Hi Aleksey, On 12/06/2016 12:58 PM, Aleksey Makarov wrote: > It turns out that this approach does not work for all the existing hardware. > There are two problems with AppliedMicro X-Gene based boards > ([discussion], [v1]): > > 1. Their console is a 16550 port that requires 32-bit access. Now SPCR does not > have any method to specify this. > > 2. Some of the boards don't use the "standard" 16550 clock rate so supplying > a baud rate makes it change to a random baud rate. > > Patch 1/4 uses 'Register Bit Width' field of the ACPI Generic Address > Structure that specifies the address of the UART registers to > decide if the driver should use "mmio32" access instead of "mmio". > This fixes problem 1 for existing hardware/firmware. > > To fix problem 2, I suggest to introduce a new value '0' for the "Baud Rate" > field of SPCR (now this value is reserved). I would like to discuss if this > could be added to SPCR spec and will fix the problem. Part 1 could well be solved in this way, provided it can be made part of the mainstream specification. It seems fairly reasonable, however. I'm not sure I subscribe to part 2 because there could be all manner of havoc changing the interpretation of existing zero values. That is why I personally favor an AppliedMicro SPCR subtype specific to them. That all said, I did discuss exactly part 2 with the folks responsible for the SPCR specification and they are thinking about their preferred solution, which will likely either be a new subtype for Applied, or perhaps allow for what you describe. I will followup when I know. Jon. -- Computer Architect | Sent from my Fedora powered laptop