Commit Graph

8 Commits

Author SHA1 Message Date
li feng
1c7baaf71f I2C: i2c_raw_mode() should only touch I2C port specified
After I2C unwedge, *all* I2C ports will be re-initialized in
i2c_raw_mode() by gpio_config_module(MODULE_I2C, 1);
This means *all* I2C pins will be programmed as	GPIO then enable I2C
alternate function.

If I2C Unwedge happened while there is an active I2C transacation on
another port, the active I2C transaction will be corrupted, since the
pins will be temporary programmed as GPIO Output High.

BUG=chrome-os-partner:40519
TEST=Warm-reboot test on Cyan EVT and no discharging while AC is on.
BRANCH=none

Change-Id: I3be1d5c60bf4ab385bc077202406ec7abd8b2add
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/287493
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Denny Iriawan <denny.iriawan@intel.com>
2015-07-25 14:49:31 +00:00
Dino Li
edb53663dd nds32: remove macro "RO"
"RO" is a workaround for GP base instructions.
And now we have added "-mno-gp-direct" option in the NDS32 toolchain.
So the compiler would not generate GP base instructions directly,
and we can remove this "RO".

Signed-off-by: Dino Li <dino.li@ite.com.tw>

BRANCH=none
BUG=chrome-os-partner:24378
TEST=console "version" and "gpioget"

Change-Id: I23cb6374fb8eb57081d713bf5c70b80a87dd2fb5
Signed-off-by: Dino Li <dino.li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/281862
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
2015-07-01 03:49:14 +00:00
Bill Richardson
62a9075435 cleanup: Don't admit the existence of unimplemented gpios
For boards with unimplemented GPIOs, don't display those GPIOs in
the output of "gpioget" or accept them as signal names in "gpioset".

BUG=none
BRANCH=none
TEST=manual

Pick a board with an unimplemented GPIO (search board/*/gpio.inc
for UNIMPLEMENTED), run "gpioget" and "gpioset". It shouldn't
show up.

Change-Id: I343ece7d6df5fa09fda8418e3f3148d74f1540ae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251012
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2015-02-20 02:59:52 +00:00
Mohammed Habibulla
2457b509cc Added v1 version of ectool gpioget supporting more functions
ectool gpioget             - returns all GPIOs (with flag info)
ectool gpioget <GPIO_NAME> - get value of <GPIO_NAME>
ectool gpioget count       - returns number of GPIOs
ectool gpioget all         - returns all GPIOs (with flag info)

BUG=chromium:344969
TEST="ectool gpioget [<subcmd> <GPIO_NAME>]" returns correct information
on squawks
BRANCH=none

Change-Id: Ib6f0d8135a76501f08b084bfd7eb1f2689d5d6e0
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196680
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2014-04-29 03:11:16 +00:00
Louis Yung-Chieh Lo
3f00af41c4 nyan: don't touch GPIO setting while init alternate functions.
Old code reset some GPIO configurations with af->flags = 0 while
gpio_config_module(). This is bad because it could lead unexpected
behavior on the bus.

New code accepts GPIO_DEFAULT flag so that it doesn't touch the
GPIO setting while configuring alternate functions. This should not
effect other boards unless the GPIO_DEFAULT is set on that board.

BUG=chrome-os-partner:24607
BRANCH=nyan
TEST=run on nyan rev 3.12. No "SPI rx bad data" at boot. UART and i2c good.

Change-Id: Id451cfae21e1d764452429dc5adfe1317ff5b140
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181135
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2014-01-03 23:04:23 +00:00
Vincent Palatin
96e034f366 nds32: WORKAROUND for toolchain bug on rodata
Sometimes the toolchain tries to put a relocation which is not suitable
to access variables in a read-only section.

The nds32 gcc uses GP-relative signed 17-bit relocation to access
variables stored in .rodata (eg lwi.gp $r0, [ +gp ])
That's wrong since $gp is pointing in the middle of .data and .bss in
the SRAM, while .rodata is sitting in flash.
Since on IT8380, the flash is at 0x00000 and the SRAM is at 0x80000
(512kB further), the linker will fail trying to create the signed 17-bit
relocation (it detect that it needs to truncate it)

Force the compiler to put another relocation as a workaround for now.

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BRANCH=none
BUG=chrome-os-partner:24378
TEST=./util/make_all.sh ; make BOARD=it8380dev
check "version" and "gpioget" on spring, link and it8380dev.

Change-Id: Ife50adf3a26be28f113292f73a1a70e8d74b5d8c
Reviewed-on: https://chromium-review.googlesource.com/176913
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
2013-12-10 19:17:59 +00:00
ChromeOS Developer
718f4bb5e3 Allow "ectool gpioget" to run on write protected machines
BRANCH=none
BUG=chrome-os-partner:23608
TEST=Run "ectool gpioget GPIO_LID_OPEN" on a write protected machine

Change-Id: I578ca2828f66d6f4463150f5e108484115a977e8
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174821
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2013-10-29 02:59:12 +00:00
Randall Spangler
8cf03ac056 Move source files to driver/ and power/ subdirs
The common/ subdir was getting cluttered.  Move drivers for external
components to a new driver/ tree, and move what used to be called
chipset_*.c to a new power/ directory.

This does not move/rename header files or CONFIG options.  That will
be done in subsequent steps, since moving and modifying .c files in
the same CL is harder to review.

BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests

Change-Id: I67a3003dc8564783a320335cf0e9620a21982d5e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173601
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
2013-10-23 20:07:25 +00:00