From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBovCONAm+GRyp5PU0bvtxHHsAjLcHzue7EqPspvApeNQ6LhtgyMdnAJp8naPeUxGyiaHu0oa ARC-Seal: i=1; a=rsa-sha256; t=1514740118; cv=none; d=google.com; s=arc-20160816; b=GZedbIWdhtcHI4xeLvQD6TGnvam8D9EQNTXJ9w1sGQsZa3Mx5fAZh3jQq0fp6+RMn/ y0V0Wd+f5PmXT7zAYVg4MQgnEkH4wvUVUfHxT/mjdmO+0Ylm1YGCBorAgMcG2wnt67yB o6pP4nrTb2xw9LnXtHdPbvBQf52OkBpPyiIP8vY4u/nxCrh6ct3owNG3W11VZQ/IVuBU EQ4B5rboSpGyldfoP0DDwhboDyGyGmdaRqRu8ZcPl/D6ZKw8/TYSRNkjU1EVdf11s5Rk KuNSKwkPaOjzoEALeUDCqhmfUkiDKQ2Dt17uAw5gAXly1oNmsMWbVQazmkATrhI7dzy5 4C2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Mk3htifsUak8S6zIgf0PoKBUAM5BIk8SmI1+nfGb4dQ=; b=dW01T6BpQASltJ2jsCYkc2OWhhHYNqdRBT+yvfPqTe3EwmiHeEukAasEtVEo40aGDK TB5vD8MYnQYHRJdRhmpx/jRU6H4AutdW6tW6eEqKdtiIymI80bvQtZGZ9+p9rxk9A8jt oRu3fEyk8g+5rUCFh9+Dpy0XbPd7rkPReALFXp6ElucQgwtUYozMeCBHT0AZ/4fLlxaO DRzjJM33RCKMXKIold5/kI5WdkXmHgvDSorhcUg6SbCfkxUJPYcToqX+HSME8KAsMAAh el/ptTpnY1J6cQoEY8SZvKzIyfo4RCJ3cNKxTODWa7wptXiYBbmwT0TOtbUB0VB0R9UL sLlQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of haiyue.wang@linux.intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=haiyue.wang@linux.intel.com Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of haiyue.wang@linux.intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=haiyue.wang@linux.intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,486,1508828400"; d="scan'208,217";a="6529355" Subject: Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI To: Arnd Bergmann Cc: Joel Stanley , gregkh , Linux Kernel Mailing List , Mark Brown , linux-spi References: <1514512387-27113-1-git-send-email-haiyue.wang@linux.intel.com> From: "Wang, Haiyue" Message-ID: Date: Mon, 1 Jan 2018 01:08:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------83D996212428A9A756282AC1" Content-Language: en-US X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1588081316766464367?= X-GMAIL-MSGID: =?utf-8?q?1588320134939461765?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: This is a multi-part message in MIME format. --------------83D996212428A9A756282AC1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Arnd, Thanks for your reply. Happy new year! :-) BR, Haiyue On 2017-12-31 07:10, Arnd Bergmann wrote: > On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang > wrote: >> When PCH works under eSPI mode, the PMC (Power Management Controller) in >> PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in >> dead loop if no SUS_ACK assert. This is the basic requirement for the BMC >> works as eSPI slave. >> >> Also for the host power on / off actions, from BMC side, the following VW >> (Virtual Wire) messages are done in firmware: >> 1. SLAVE_BOOT_LOAD_DONE / SLAVE_BOOT_LOAD_STATUS >> 2. SUS_ACK >> 3. OOB_RESET_ACK >> 4. HOST_RESET_ACK > I have not looked at the driver contents yet, but I'm adding the SPI > maintainer and > mailing list to Cc here for further discussion. Can you clarify how > the eSPI slave > mode relates to SPI slaves that we already support? I was under the impression > that the difference between SPI and eSPI is mainly on the master side, but that > any SPI slave can also act as an eSPI slave. Would this driver fit into the SPI > slave framework, possibly with some extensions to the generic abstraction? In simple word, the eSPI uses the SPI interface pin definition, but it will replace Low Pin Count (LPC) interface. From its name, sure, it will confuse you! ;-) > It also seems rather inflexible to have a single driver that is responsible both > for the transport (eSPI register level interface for ASPEED) and the high-level > protocol (talking to an Intel PCH), since either half of the work could be > done elsewhere, using either a different eSPI slave implementation, or > a different > host architecture) Yes, eSPI has the architecture such as transaction layer, link Layer; all of it is about the **silicon** design. That's why I put the driver under /misc directory, not /spi directory. > Arnd --------------83D996212428A9A756282AC1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Arnd,

Thanks for your reply. Happy new year! :-)

BR,
Haiyue

On 2017-12-31 07:10, Arnd Bergmann wrote:
On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang
<haiyue.wang@linux.intel.com> wrote:

When PCH works under eSPI mode, the PMC (Power Management Controller) in
PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in
dead loop if no SUS_ACK assert. This is the basic requirement for the BMC
works as eSPI slave.

Also for the host power on / off actions, from BMC side, the following VW
(Virtual Wire) messages are done in firmware:
1. SLAVE_BOOT_LOAD_DONE / SLAVE_BOOT_LOAD_STATUS
2. SUS_ACK
3. OOB_RESET_ACK
4. HOST_RESET_ACK

I have not looked at the driver contents yet, but I'm adding the SPI
maintainer and
mailing list to Cc here for further discussion. Can you clarify how
the eSPI slave
mode relates to SPI slaves that we already support? I was under the impression
that the difference between SPI and eSPI is mainly on the master side, but that
any SPI slave can also act as an eSPI slave. Would this driver fit into the SPI
slave framework, possibly with some extensions to the generic abstraction?
In simple word, the eSPI uses the SPI interface pin definition, but it will replace Low Pin Count (LPC)
interface. From its name, sure, it will confuse you! ;-) 
It also seems rather inflexible to have a single driver that is responsible both
for the transport (eSPI register level interface for ASPEED) and the high-level
protocol (talking to an Intel PCH), since either half of the work could be
done elsewhere, using either a different eSPI slave implementation, or
a different
host architecture)
Yes, eSPI has the architecture such as transaction layer, link Layer; all of it is about the **silicon**
design. That's why I put the driver under /misc directory, not /spi directory. 
       Arnd

--------------83D996212428A9A756282AC1--