With the upcoming change to add a new command to get/set/clear host
events and masks, it seems to be the right time to bump up the host
events and masks to 64-bit. We are already out of available host
events. This change opens up at least 32 bits for new host events.
Old EC commands to operate on host events/masks will still deal with
lower 32-bits of the events/mask. On the other hand, the new command
being added will take care of the entire 64-bit events/masks. This
ensures that old BIOS and kernel versions can still work with the
newer EC versions.
BUG=b:69329196
BRANCH=None
TEST=make -j buildall. Verified:
1. hostevent set 0x4000 ==> Sets correct bit in host events
2. hostevent clear 0x4000 ==> Clears correct bit in host events
3. Kernel is able to query and read correct host event bits from
EC. Verified using evtest.
4. Coreboot is able to read correct wake reason from EC. Verified
using mosys eventlog list.
Change-Id: Idcb24ea364ac6c491efc2f8dd9e29a9df6149e07
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/770925
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add a new LPC helper routine lpc_resume_clear_masks that can be used
to clear SCI, SMI and wake masks upon resume from S3. This is done to
mask the events until host explicitly unmasks them.
It also ensures that these masks do not get reset on resume from S0ix
where the host does not re-configure these masks.
BUG=b:68669668
BRANCH=None
TEST=Verified following:
1. make -j buildall
2. On resume from S0ix, SCI mask is not reset.
3. On resume from S3, SCI mask is reset and then set again by host request.
Change-Id: I17a86bd60ef066b3716fb79ecce62f311eb45509
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
keyboard/button init are responsible for checking if user requested
manual recovery. However, by this time, hook init is not run and hence
host event set operation for manual recovery is dropped. This change
adds a call to lpc_init_mask before keyboard/button init operations
are performed.
BUG=b:68189465
BRANCH=None
TEST=Verified that manual recovery works fine. Recovery using software
command works too:
reboot ap-off
hostevent set 0x4000
powerb
Change-Id: I15cb648d4b253a523293c7ab2cd3e8e08e31a763
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/735799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a new mask type (ALWAYS_REPORT mask) that is set by default to
certain host events that should always be reported to the host
irrespective of the state of SCI, SMI and wake masks. This mask
includes host events like critical events resulting in shutdown or
reboot, events that are consumed by BIOS, etc.
Now that ALWAYS_REPORT mask is added, this change also updates the way
EC manages set/query operations for host events:
1. During set operation, EC will check if the host event is present in
any of the 4 masks - SCI, SMI, wake and always report. If yes, then it
is set in hostevents.
2. During query operation, EC will extract the lowest set event from
hostevents, clear it and return it back to the host.
In order to reflect the above change in EC behavior, a new feature bit
is used EC_FEATURE_UNIFIED_WAKE_MASKS. This allows the host to decide
when wake mask needs to be set before checking for host events.
BUG=None
BRANCH=None
TEST=make -j buildall. Also verified following:
1. Wake from S3 works as expected. Host is able to log correct wake
sources (Verified power button, lid open, base key press and tablet
mode change on soraka).
2. Wake from S5 works as expected. Host is able to log correct wake
sources (Verified power button, lid open on soraka).
3. Wake from S0ix works as expected (Verified power button, lid open
on soraka).
4. Software method to trigger recovery still works fine:
reboot ap-off
hostevent set 0x4000
powerb
Change-Id: I62e5c1f82247c82348cd019e082883d86ec2688f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/719578
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of duplicating the handling of host events and host event
masks in chip lpc drivers, add routines in common code to provide
basic functions like setting/getting of masks, setting/getting of
events and handling of masks transitions across sysjump.
BUG=None
BRANCH=None
TEST=make -j buildall. Verified following:
1. Event masks are correctly retained across sysjumps.
2. Wake from S3 works fine.
3. Wake from S0ix works fine.
4. SCI generated correctly.
Change-Id: Ie409f91b12788e4b902b2627e31ba5ce40ff1d27
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/707771
Reviewed-by: Shawn N <shawnn@chromium.org>
Prior x86 boards have had GPIO for toggling RCIN directly on the PCH,
although many likely had HW-assisted methods as well.
With eve we need to generate an eSPI Virtual Wire for RCIN, but in reality
software control over RCIN Virtual Wire is not available with the npcx EC,
so the legacy LPC interface for pulsing KBRST must be used instead as this
is the only way to generate RCIN.
This method will likely vary on different EC chips, but for skylake it
can just be abstracted into the LPC module.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=successful 'apreset warm' on eve EC console
Change-Id: I7f9e7544a72877f75d05593b5e41f2f09a50e1c9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400037
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
In the S0 <-> S3 transition, Coreboot sends EC messages to set/clear the
wake masks when the SMI is invoked. For S0ix, EC sets and clears the
wake mask via this patch.
These functions are directly invoked from the state machine transition states.
During S0ix entry, the wake mask for lid open is enabled. During S0ix exit,
the wake mask for lid open is cleared. All pending events are also cleared
BRANCH=none
BUG=chrome-os-partner:48834
TEST=test lidopen in S0ix
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Change-Id: I52a15f502ef637f7b7e4b559820deecb831d818f
Reviewed-on: https://chromium-review.googlesource.com/320190
Commit-Ready: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
mutex_lock() is called from MEC1322_IRQ_ACPIEC0_IBF
interrupt context, causing deadlock and assertion
in __wait_evt().
In the interrupt context it now checks for mutex lock first.
If the mutex is already locked,, it will disable ACPI
interrupts and defer the memmap mutex lock.
Added LPC interrupt disable/enable functions as needed.
Increased deferred function count where needed.
BRANCH=None
BUG=chrome-os-partner:40820
TEST=Test for suspend-resume, cold, warm reboots and
other general stability.
Change-Id: I3dda0d4635a6b6281faf200c8c7b6fcba8877254
Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/280418
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
Some platforms are unable to access the 900h-9ffh region over LPC and
must instead access memmap data through the ACPI CMD / DATA ports. To
avoid racing with data updates, disallow changes to multi-byte memmap
data while in burst mode.
Linux currently enables burst mode when accessing multi-byte data and
disables it immediately afterward, though the ACPI spec defines burst mode
in a more general way.
BUG=chrome-os-partner:38224
TEST=Manual on Samus. Undefine LPC_MEMMAP and modify asl to move memmap
data to ERAM at offset 0x20. Verify system boots cleanly and battery
status is updated immediately on plug / unplug.
BRANCH=None
Change-Id: Ib848bdb491fdfece96ad0cee7a44ba85b4a1a50b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262072
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
In some cases, the system will boot to S0 from the point of view of
the EC, but PLTRST# will never deassert. Work around this by waiting
50 ms for PLTRST# to deassert. If it doesn't, force the chipset all
the way down by deasserting RSMRST#, then pulse the power button to
turn it back on.
Also add a powerfail debug command to simulate this failure event, so
that the recovery process can be tested.
Add API to the LPC module to get the state of PLTRST#, and to the
power button state machine to force it released when we shut down the
chipset and and force another power button pulse as we reset the
chipset.
BUG=chrome-os-partner:28422
BRANCH=baytrail
TEST=1. Boot system. Should boot normally. Shut system down.
2. powerfail
3. Boot system. On the EC console, should see the system come up,
go back down through G3S5, then come back up. From the user's
point of view, it just boots.
1. Boot system. Should boot normally. (That is, powerfail is not sticky)
Change-Id: Ia57f196606f79b9f2fce7d9cd109ab932c3571aa
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197523
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add i8042 output port commands (0xf0-0xff), I8042_ENABLE_A20 and
I8042_DISABLE_A20.
BUG=chrome-os-partner:13119,
BRANCH=None
TEST=Tested on W7 installer. No KB error shown on EC console.
Change-Id: I9ad1fd7baa10683ef18ccf13faf09dc0cefcca0a
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34994
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tidied comments, and removed handling of ACPI events on host command
port (not needed since EVT hardware is now EOL'd).
BUG=chrome-os-partner:15579
BRANCH=none
TEST='ectool hello' succeeds
Change-Id: I063382b9981f713ba23f7714b4ccb7faa957b411
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36804
Now both copies of the event state live in host_event_commands.c, and
lpc / memmap just shadows the main copy.
BUG=chrome-os-partner:11172
TEST=manual
Boot system. should see events 0x2000, 0x80, 0x08 get set and then cleared.
At U-boot prompt, type on keyboard. Should set event 0x1000 get set,
but only on the first keypress (because U-boot doesn't consume that
event).
Then from EC console,
hostevent clear 0x1000 -> see event 0x1000 clear
hostevent clear 0x1000 -> no debug output (it's already clear)
hostevent clearb 0x1000 -> see event copy B 0x1000 clear
hostevent clearb 0x1000 -> no debug output (copy B is already clear)
Change-Id: I855c035865649ba1490cd9027157d5bcdcc9895f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27321
The phenomenon is that there is a char on-hold in port 0x60 and the kernel
never picks it up. Hence the keyboard cannnot be recognized after resume.
It comes from multiple reasons:
1. The command I8042_CMD_RESET_BAT(0xff) and I8042_CMD_ENABLE(0xf4) didn't
clean the buffer.
2. clean_underlying_buffer() has clean the queue, but forgot to clean the
TOH (TO Host). Add keyboard_clean_buffer() to clean the TOH (To Host).
3. When KB interrupt is just enabled, the IRQ didn't sent if there is
a char queued in buffer already. keyboard_resume_interrupt() solves
this.
4. Not all keyboard reset should reset the buffer. Only the enable/disble
of controller RAM should NOT reset buffer. Other enable/disable
should clean the buffer.
5. i8042 commands (those commands to port 0x64) should NOT return ACK
even the parameter byte(s) goes to port 0x60.
6. Keyboard was disabled by kernel, but key stroke still sent to host
(this needs the BIOS to fix).
Also fix the minor issues:
1. I8042_CMD_RESEND should not return I8042_RET_ACK.
2. I8042_DIS_KB/I8042_ENA_KB should effect the controller RAM content.
3. only send out the scan code when keyboard is enabled.
4. add kblog command for future debug (disabled by default because it
neeeds 1KB of memory).
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
BUG=chrome-os-partner:9525
TEST=tested on link. Start from S0.
1. Run powerd_suspend.
2. Expect system is in S3.
3. Press any key to wake up system.
4. Expect system is up and keyboard is working.
5. repeat for 20+ times.
Change-Id: I1c48822687d7c1f7ef0e8d8bca54bf9b05fd785f
Preparatory work to use common host command code between ARM and x86.
Every command sends back explicitly the size of the response payload.
The size of the response defaults to 0 ond can be updated.
Add a protocol version number returned as command 0x00 to help with
backward compatibility.
move a couple of function from lpc specific header to host commands to
be able to implement them for the I2C link.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9614
TEST=make BOARD=link
Change-Id: I6a28edf02996ddf6b7f32a3831d07d5f0271848f
This covers modules which need to initialize before task_start(), but
don't particularly care in what order they're initialized.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=if it boots, it works
Change-Id: I69829aac8d1c3c14ee04916a794b84bbf03a09eb
This works similar to SCI/SMI events, but triggers a separate
level-sensitive signal to the PCH instead.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8514
TEST=manual
From EC console:
gpioget PCH_WAKEn --> should be 1
hostevent wake 0x1
close lid switch (with magnet)
hostevent -> should show wake mask 0x1, raw events 0x1
gpioget PCH_WAKEn --> should be 0
hostevent clear 0x1
hostevent -> should show raw events 0
gpioget PCH_WAKEn --> should be 1
Change-Id: I29832c1dc30239a98987578f07dfeb25791dde11
This is necessary to support SCI/SMI events.
Note that this breaks compatibility with previous ectool builds - and
probably also breaks flashrom support.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:8253
TEST='ectool hello' and 'ectool flashinfo' still work
and 'ectool usbchargemode 3 1' fails with error 2
Change-Id: If39e5b6e7cdcec1b5ec765594e8492925b430b10
This will allow more efficient access to EC-provided data (temperature,
fan, battery) by the main processor.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7857
TEST='ectool hello' from link main processor should still work
Change-Id: I2dc683f3441b34de9fb4debf772e386b9fdcfa82
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:7488
TEST=type things into the x86 console UART; should appear on the u-boot prompt
Change-Id: I75fd225842c03d11d79280fb7453ad37695279e3
The problem comes from the different assumption of interrupt mode in EC and
the PCH. The PCH assumes IRQ1 is edge-triggered and triggered at a rising edge.
However, the auto-IRQ functino of EC is level-triggered and uses low-active to
assert an IRQ. This makes the deadlock so that the kernel never gets an
interrupt until a byte is manually pulled from host.
So, the solution is manually firing an IRQ_1 to host after EC puts a byte to
port 0x60. Note that the auto IRQ needs to be disabled in order to avoid
the interference with manual IRQ generation.
This CL also moves chip specific code to lm4/lpc.c and handle some minor
keyboard commands.
BUG=none
TEST=on hacked baord.
Change-Id: Ib57f5a4d749cb019e4c3c00da110054c4f335c7b
LPC module no longer directly talks to UART registers, and vice-versa.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST='ectool sertest' on target system
Change-Id: Id070c0d849bdfe91c752e0af651d357b695d2648
(cherry picked from commit ab8c3c2b8e3b08a4bf5573cda3a12dd3a384e67d)
