From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBouqeZ+1wKOMqWD97KOKGwrRCpcvA3nS37Dc9INbSQseo9S+f498q+c9jNWUj0tE1RmBpd42 ARC-Seal: i=1; a=rsa-sha256; t=1514739890; cv=none; d=google.com; s=arc-20160816; b=gJl5ALcuIGabI5h1WRK4/U2OvWiJhCTlWgB8GnogrEUgX/Xj6mMHBdw4VSorytv22o XZExFwfSmWgSIvzx7JCRBZAvWPW5QaFNPjXKS3Q+/5JLPIfcNXZa8opeCfRMoZqef0Ou 2J6BpeM1PO4m8XI6M2TfjkLJMkWucx+pR5hlTnH3K0lsCa54Hya0EB3VSK+m+zJH1fVk 4/NEEa5VQLT/NXQDErw6ONdpzxK4vWKlfQfkNH6P8PjWtl9pV/6wvnNXeF/UJ38VOJ0U JoLXjcvD3cAN5y1FKirqlhBrEpvzvweLGLwiFZpPXcuZYqW60hKjP1z2YBuqp8c3yYcB avyg== 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=KGMEUwFPMLU7wBwQMtqix5eBvcOdgOfsh7bGmDb5ykU=; b=UwZn3g/Tpj3UIulFiedjFcU1FsAealuRzcEK06WzjcBVPNBRdxqCE3U2kwuPy8kOXc fNrF05Zrhkp6DDLC1W0SSyMEL+ErCWIyknnJTWRNnr6IT+9LOpSXcGXHr/i+Npl+YWGD syTz7BdyfoLqen+wjTs57VrMDYA2zGhy7LXZPf9Pkc1KYdASxS6I0EBwpyJUVB/TwvkR bpV5aopjB8jfT++HFTq3zAU+lCbIkJit6dyIk+53Z06R+t7d9BKvZ3uAuQ4CPCr0l1f+ zPOGzSbdM0NP83DEsPOOm8mNGQ8FtmMLILoQ3YUeX+BYgjDdgBifbc370MK5NYDvgeD3 e3Tw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of haiyue.wang@linux.intel.com designates 192.55.52.115 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 192.55.52.115 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="6529045" 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: <742d4e69-0af9-cafe-67d1-ad9003757c46@linux.intel.com> Date: Mon, 1 Jan 2018 01:04:48 +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="------------5281ACCFA67BE66BDE01E444" Content-Language: en-US X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1588081316766464367?= X-GMAIL-MSGID: =?utf-8?q?1588319895720560119?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: This is a multi-part message in MIME format. --------------5281ACCFA67BE66BDE01E444 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Arnd, Thanks for your reply. Happy new year! :-) 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 --- BR, Haiyue --------------5281ACCFA67BE66BDE01E444 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Arnd,

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

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

---
BR,

Haiyue
--------------5281ACCFA67BE66BDE01E444--