On 2018-01-04 01:08, Wang, Haiyue wrote:
On 2018-01-04 00:43, Wang, Haiyue wrote:
On 2018-01-03 23:17, Arnd Bergmann wrote:
On Wed, Jan 3, 2018 at 3:21 AM, Wang, Haiyue
wrote:
On 2018-01-03 00:23, Arnd Bergmann wrote:
On Tue, Jan 2, 2018 at 4:36 PM, Wang,
On 2018-01-04 01:08, Wang, Haiyue wrote:
On 2018-01-04 00:43, Wang, Haiyue wrote:
On 2018-01-03 23:17, Arnd Bergmann wrote:
On Wed, Jan 3, 2018 at 3:21 AM, Wang, Haiyue
wrote:
On 2018-01-03 00:23, Arnd Bergmann wrote:
On Tue, Jan 2, 2018 at 4:36 PM, Wang, Haiyue
wrote:
On 2018-01-02
On Wed, Jan 3, 2018 at 3:21 AM, Wang, Haiyue
wrote:
> On 2018-01-03 00:23, Arnd Bergmann wrote:
>> On Tue, Jan 2, 2018 at 4:36 PM, Wang, Haiyue
>> wrote:
>>> On 2018-01-02 23:13, Arnd Bergmann wrote:
>
> On 2017-12-31 07:10, Arnd
On Wed, Jan 3, 2018 at 3:21 AM, Wang, Haiyue
wrote:
> On 2018-01-03 00:23, Arnd Bergmann wrote:
>> On Tue, Jan 2, 2018 at 4:36 PM, Wang, Haiyue
>> wrote:
>>> On 2018-01-02 23:13, Arnd Bergmann wrote:
>
> On 2017-12-31 07:10, Arnd Bergmann wrote:
On the slave side, it seems that
On Wed, Jan 3, 2018 at 3:32 PM, Mark Brown wrote:
> On Wed, Jan 03, 2018 at 10:28:22PM +0800, Wang, Haiyue wrote:
>
>> Should send to like this ? Because I add patch for Aspeed chip:
>
>> ./scripts/get_maintainer.pl drivers/misc/aspeed-lpc-snoop.c
>> Joel Stanley
On Wed, Jan 3, 2018 at 3:32 PM, Mark Brown wrote:
> On Wed, Jan 03, 2018 at 10:28:22PM +0800, Wang, Haiyue wrote:
>
>> Should send to like this ? Because I add patch for Aspeed chip:
>
>> ./scripts/get_maintainer.pl drivers/misc/aspeed-lpc-snoop.c
>> Joel Stanley (maintainer:ARM/ASPEED MACHINE
On 2018-01-03 22:32, Mark Brown wrote:
On Wed, Jan 03, 2018 at 10:28:22PM +0800, Wang, Haiyue wrote:
Should send to like this ? Because I add patch for Aspeed chip:
./scripts/get_maintainer.pl drivers/misc/aspeed-lpc-snoop.c
Joel Stanley (maintainer:ARM/ASPEED MACHINE
On 2018-01-03 22:32, Mark Brown wrote:
On Wed, Jan 03, 2018 at 10:28:22PM +0800, Wang, Haiyue wrote:
Should send to like this ? Because I add patch for Aspeed chip:
./scripts/get_maintainer.pl drivers/misc/aspeed-lpc-snoop.c
Joel Stanley (maintainer:ARM/ASPEED MACHINE SUPPORT)
Arnd Bergmann
On Wed, Jan 03, 2018 at 10:28:22PM +0800, Wang, Haiyue wrote:
> Should send to like this ? Because I add patch for Aspeed chip:
> ./scripts/get_maintainer.pl drivers/misc/aspeed-lpc-snoop.c
> Joel Stanley (maintainer:ARM/ASPEED MACHINE SUPPORT)
> Arnd Bergmann
On Wed, Jan 03, 2018 at 10:28:22PM +0800, Wang, Haiyue wrote:
> Should send to like this ? Because I add patch for Aspeed chip:
> ./scripts/get_maintainer.pl drivers/misc/aspeed-lpc-snoop.c
> Joel Stanley (maintainer:ARM/ASPEED MACHINE SUPPORT)
> Arnd Bergmann (supporter:CHAR and MISC DRIVERS)
On 2018-01-03 19:38, Mark Brown wrote:
On Sun, Dec 31, 2017 at 12:10:51AM +0100, 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
On 2018-01-03 19:38, Mark Brown wrote:
On Sun, Dec 31, 2017 at 12:10:51AM +0100, 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
On Sun, Dec 31, 2017 at 12:10:51AM +0100, 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
On Sun, Dec 31, 2017 at 12:10:51AM +0100, 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
On 2018-01-03 00:23, Arnd Bergmann wrote:
On Tue, Jan 2, 2018 at 4:36 PM, Wang, Haiyue
wrote:
On 2018-01-02 23:13, Arnd Bergmann wrote:
On 2017-12-31 07:10, Arnd Bergmann wrote:
It also seems rather inflexible to have a single driver that is
responsible both
On 2018-01-03 00:23, Arnd Bergmann wrote:
On Tue, Jan 2, 2018 at 4:36 PM, Wang, Haiyue
wrote:
On 2018-01-02 23:13, Arnd Bergmann wrote:
On 2017-12-31 07:10, Arnd Bergmann wrote:
It also seems rather inflexible to have a single driver that is
responsible both
for the transport (eSPI
On Tue, Jan 2, 2018 at 4:36 PM, Wang, Haiyue
wrote:
> On 2018-01-02 23:13, Arnd Bergmann wrote:
>>> On 2017-12-31 07:10, Arnd Bergmann wrote:
It also seems rather inflexible to have a single driver that is
responsible both
for the transport (eSPI
On Tue, Jan 2, 2018 at 4:36 PM, Wang, Haiyue
wrote:
> On 2018-01-02 23:13, Arnd Bergmann wrote:
>>> On 2017-12-31 07:10, Arnd Bergmann wrote:
It also seems rather inflexible to have a single driver that is
responsible both
for the transport (eSPI register level interface for
On 2018-01-02 23:13, Arnd Bergmann wrote:
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
On 2018-01-02 23:13, Arnd Bergmann wrote:
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
> 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
> 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.
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
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
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,
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,
26 matches
Mail list logo