LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jon Masters <jcm@redhat.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"leif.lindholm@linaro.org" <leif.lindholm@linaro.org>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	andre.przywara@arm.com
Subject: Re: inverse mapping from a struct console to device
Date: Tue, 27 Jan 2015 06:54:18 -0500	[thread overview]
Message-ID: <54C77C6A.8000508@redhat.com> (raw)
In-Reply-To: <20150127101440.GA17721@leverpostej>

On 01/27/2015 05:14 AM, Mark Rutland wrote:
> On Tue, Jan 27, 2015 at 03:06:35AM +0000, Jon Masters wrote:
>> On 01/26/2015 03:50 PM, Mark Rutland wrote:
>>> On Mon, Jan 26, 2015 at 07:40:58PM +0000, Jon Masters wrote:
>>>> Hi Folks,
>>>>
>>>> TLDR: I need a back reference from a console struct to its device. I
>>>> can't see an easy way to do this right now without adding one?
>>>
>>> I don't think that's quite what you need. All you need is to be able to
>>> refer to the SPCR at serial probe time (more on that below), when you
>>> should have the data you want.
>>
>> Hmm. I wanted to do it in console_register due to the existing logic for
>> adding a preferred console there. But that's a silly reason.
>>
>>>> I've a quick question. I have prototype code that parses an ACPI table
>>>> known as the SPCR (Serial Port Console Redirection - exists on both x86
>>>> and ARM systems). It finds the correct serial device (but it's not a
>>>> Linux specific DT-style solution so there's no "console=" parameter
>>>> embedded in it or something)
>>>
>>> In DT we have /chosen/stdout-path which offers analagous functionality.
>>> It is independent of the command line, and has a standard set of
>>> parameters (<baud>{<parity>{<bits>{<flow>}}}).
>>
>> Hmm. I thought it was embedding a Linux specific console parameter, but
>> I see when I actually check the code and the Documentation (sorry) that
>> it is indeed similar in capability. Which is awesome. I'll do similar.
>>
>>> To make this work we check against the stdout-path when we register the
>>> UART. Take a look at of_console check (called from uart_add_one_port).

I have working SPCR setup on a system using an 8250 interface (Mustang)
with ACPI. The preferred console comes up nicely. So, that's good.

>> Great. Thanks. I looked at modifying uart_add_one_port, but I wasn't
>> convinced it was called by every serial driver (for example, the
>> sbsauart driver). I don't know the tty/serial code as well as I'd like.
>> But I'll implement it the same way as in the OF case for the moment, and
>> if we need to fix up a driver or two we can always do that.

Confirmed that the existing sbsauart driver I have doesn't use
uart_add_one_port (it's an older driver based on Linaro's code). It
seems like we need to update, which I'll follow up on separately.

> The SBSA UART is a bit of a special case, given it cannot be
> reconfigured. While Andre's SBSA UART driver [1] will call
> uart_add_one_port (as the PL011 driver seems to currently), I believe
> any configuration is ignored.

Indeed. And we don't need to reconfigure it, but we still want to know
which console to use since it could be an SBSA or 8250. And in theory
someone could build something else (but not conforming to SBBR).

> In the DT case, we'd expect the SBSA UART node to have a current-speed
> property describing the fixed, preconfigured speed. This has no bearing
> on the operation of the driver (because there's nothing to configure)
> and is only used to report the speed to userspace.
> 
> I guess we don't have something on the ACPI node, and you want to use
> the SPCR to determine the preconfigured rate in this case?

Nope, I just want to know that I'm using the SBSA console and not
another. Hence the SPCR will tell me which to set as preferred.

Here's an example of the data we get in the SPCR for reference:

[0012]               Serial Port Register : [Generic Address Structure]
[0001]                           Space ID : 00 [SystemMemory]
[0001]                          Bit Width : 08
[0001]                         Bit Offset : 00
[0001]               Encoded Access Width : 01 [Byte Access:8]
[0008]                            Address : 000000001c020000

[0001]                     Interrupt Type : 08
[0001]                PCAT-compatible IRQ : 00
[0004]                          Interrupt : 0000006C
[0001]                          Baud Rate : 07
[0001]                             Parity : 00
[0001]                          Stop Bits : 01
[0001]                       Flow Control : 00
[0001]                      Terminal Type : 00
[0001]                           Reserved : 00

The actual structure is longer, but you get the idea. I first map this
to the correct Device in the DSDT with a device_initcall that will find
the table then walk the ACPI namespace to find the corresponding device.
This is stashed so that later we can perform the same kind of comparison
that you do with DT today. I also populate options, though so far have
only bothered to implement baud rate.

>> Thanks Mark. I'll post a patch later for SPCR setup.
> 
> Great!

Just need to switch out the SBSA UART driver and test that case on e.g.
Seattle with SBSA UART. It's working as described above on Mustang-like
platforms running with ACPI as of a few minutes ago.

Jon.


  reply	other threads:[~2015-01-27 11:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-26 19:40 Jon Masters
2015-01-26 20:20 ` Greg KH
2015-01-27  3:16   ` Jon Masters
2015-01-26 20:50 ` Mark Rutland
2015-01-27  3:06   ` Jon Masters
2015-01-27 10:14     ` Mark Rutland
2015-01-27 11:54       ` Jon Masters [this message]
2015-01-27 12:30         ` Mark Rutland
2015-01-27 20:42           ` Jon Masters
2015-01-28 22:48             ` Peter Hurley

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=54C77C6A.8000508@redhat.com \
    --to=jcm@redhat.com \
    --cc=andre.przywara@arm.com \
    --cc=grant.likely@linaro.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --subject='Re: inverse mapping from a struct console to device' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).