All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Feng Tang <feng.tang@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Cox <alan@linux.intel.com>,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter
Date: Tue, 21 Feb 2012 19:36:24 -0800	[thread overview]
Message-ID: <4F4462B8.6030607@linux.intel.com> (raw)
In-Reply-To: <CANKRQni9E6NO39MFSak6MjQ0DtmQeviGo966Ex9ZUvai56wCjg@mail.gmail.com>



On 02/21/2012 07:10 PM, Tomoya MORINAGA wrote:
> 2012年2月22日10:59 Darren Hart <dvhart@linux.intel.com>:
>> This series does some minor clean-up to the pch_uart driver, adds support
>> for the Fish River Island II UART clock, and introduces a user_uartclk
>> parameter to aid in developing for early and changing hardware.
>>
>> Note that this series is my proposed alternative solution to that provided
>> by Tomoya MORNIAGA and Feng Tang which drops the board quirks and opts to
>> assume a 192 MHz clock on all boards. The problem with this approach is
>> that the CLKCFG register may have been set to something other than the
>> 192MHz configuration by the firmware. If so, then the pch_uart will send
>> garbage between the time the boot console is disabled and the pch_phub
>> sets the CLKCFG register again. In my case, the pch_phub PCI probe occurs
>> after the pch_uart_console_setup. Even if it happened before, the output
>> up until the PCI probing would be garbage.
>>
>> In order to support an early serial console, we cannot rely on the pch_phub
>> probe function to setup the CFGCLK register. This series relies on the board
>> quirks and doesn't force the setting of the CLKREG in the pch_phub code.
>> Instead, it aligns with what is the default configuration (defined by firmware)
>> for a given board. The user_uartclk provides a mechanism to force a specific
>> uartclk if necessary.
> 
> I think UART console function(including "early serial console") is
> used for debug use.
> 
> So, if people who want to see the boot log correctly before pch_phub installed,
> the people have only to do configure uart_clock by themselves.
> 
> So, I think default uart_clock 192MHz setting is better than Darren's opinion.
> 
> Let me know your opinion.

This patch series allows for a functional early serial console as well
as using the UART after boot. It leaves the CM-iTC board alone. So this
seems to enable all use cases, while forcing 192MHz breaks the FRI2
early serial console. I don't see an advantage to that approach other
than the obviously simpler code (which is nice, but should not trump
functionality).

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

  reply	other threads:[~2012-02-22  3:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-22  1:59 [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter Darren Hart
2012-02-22  1:59 ` [PATCH 1/4] pch_uart: Use uartclk instead of base_baud Darren Hart
2012-02-22  1:59 ` [PATCH 2/4] pch_uart: Add Fish River Island II uart clock quirks Darren Hart
2012-02-22  8:52   ` Alan Cox
2012-02-22  9:46     ` Darren Hart
2012-02-24 21:53       ` Greg Kroah-Hartman
2012-02-24 22:25         ` Darren Hart
2012-02-24 23:39           ` Greg Kroah-Hartman
2012-02-22  1:59 ` [PATCH 3/4] pch_uart: Add user_uartclk parameter Darren Hart
2012-02-22  1:59 ` [PATCH 4/4] pch_uart: Use existing default_baud in setup_console Darren Hart
2012-02-22  3:10 ` [PATCH 0/4] pch_uart: Cleanups, board quirks, and user uartclk parameter Tomoya MORINAGA
2012-02-22  3:36   ` Darren Hart [this message]
2012-02-22  4:26     ` Tomoya MORINAGA
2012-02-22  6:39       ` Darren Hart
2012-02-22  8:16         ` Tomoya MORINAGA
2012-02-22  8:59           ` Darren Hart
2012-02-22  9:25             ` Feng Tang
2012-02-22  8:58   ` Alan Cox
2012-02-22  9:55     ` Darren Hart
2012-02-22  9:55       ` Darren Hart

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=4F4462B8.6030607@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=alan@linux.intel.com \
    --cc=feng.tang@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=tomoya.rohm@gmail.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.