summaryrefslogtreecommitdiff
path: root/chip/stm32/spi.c
Commit message (Collapse)AuthorAgeFilesLines
* GPIO: Remove gpio_get_level_reg functionAnton Staaf2016-01-271-13/+8
| | | | | | | | | | | | | | | | | | | | After talking with Simon Glass about this we concluded that this was an optimization that is not needed, as such, and since it is only used in one location and only available from one chip family I'm removing it. This further simplifies the GPIO API and removes more uses of port/mask pairs. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I40754a385e0a4fa3a56d67fca1dd59fc8f3cc85a Reviewed-on: https://chromium-review.googlesource.com/323827 Commit-Ready: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: spi: clear the spi sleep mask when AP in S3.Ben Lok2015-08-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | The SLEEP_MASK_SPI will not be cleared, if SPI received a bad data. It is possible to block EC to enter deep sleep if AP send a bad packet to EC before AP goto S3/S5. In order to ensure that deep sleep can be enabled, clear SLEEP_MASK_SPI in chipset suspend hook to avoid this situation. BUG=chrome-os-partner:44170 BRANCH=None TEST=manually 1. use AP console command to let AP enter S5: > shutdown -h now 2. check the sleepmask in EC console. > sleepmask sleep mask: 00000000 Change-Id: Ib5f5c421c123d9a3c2cc6fead07c8fa515e452f1 Signed-off-by: Ben Lok <ben.lok@mediatek.com> Reviewed-on: https://chromium-review.googlesource.com/294432 Reviewed-by: Rong Chang <rongchang@chromium.org>
* stm32: Deprecate SPI protocol version 2.Aseda Aboagye2015-08-081-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Now that v3 support is in the cros_ec kernel driver and depthcharge, deprecate support for the old v2 protocol. At some point in the future, support for the v2 protocol will dropped entirely. Boards that require support for the V2 protocol should enable the following config option. #define CONFIG_SPI_PROTOCOL_V2 BUG=chrome-os-partner:20533 BRANCH=None TEST=make -j buildall tests TEST=Flash jerry, AP & EC boot successful. TEST=`ectool protoinfo` shows only version 3 supported on jerry. TEST=Flashrom still works on jerry. Change-Id: I72d3aee00879314b936cc0b1002c9883550b1f1a Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/291411 Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
* stm32: spi: Fix race condition with the enabled booleanAlexandru M Stan2015-04-281-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes the chipset task is slow enough that we might get messages from the AP before chipset_in_state(CHIPSET_STATE_ON) is true. This causes us to leave the spi off after our usual reset after every transaction (see chrome-os-partner:31390). This would put an end to any EC communications. Instead of relying on CHIPSET_STATE_ON we could just save the value of "enabled" before we turn it off, then use that as a condition instead. There shouldn't be a race condition on "enabled" because the only other place it gets modified is in the hooks, which can't preempt spi_init (which usually happens in the host command task). The only problem is that in case of a sysjump enabled will be 0, so CHIPSET_STATE_ON was left as a backup to handle that case. This fixup was squashed from Ied3788f83fef548dff3b01bec93d0e40101ba0f7 TEST=Resume minnie from "echo mem>/sys/power/state" a few times, note ec still works BUG=chrome-os-partner:39564, chrome-os-partner:39576 BRANCH=veyron Change-Id: I7c33243faebfd74dc33451024c1d75080babee03 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/267593 Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: Add delay after enabling peripheral clockVic Yang2015-02-101-0/+4
| | | | | | | | | | | | | | | | | We need a dummy read after enabling AHB peripheral clock before we can access the peripheral. For APB, we also need a dummy read for STM32F3. BRANCH=All affected BUG=chrome-os-partner:33007 TEST=make buildall Change-Id: I47f4a024dca294f555428c3f2053c1d32835ebe0 Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/246181 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* stm32f0: Pinky: Fix power leak caused by SPI at startupAlexandru M Stan2014-10-211-2/+0
| | | | | | | | | | | | | | | Seems like we were setting outputs too early during boot, sometimes causing a power leak. SPI should only turn on power levels more active than S3, not on the S5->S3 transition. BUG=chrome-os-partner:32824 BRANCH=None TEST=Pinky powers on, Scope VCC33_PMUIO and VCC33_IO, note that they're smooth Change-Id: I05c3622d124c2539222b883b895bc9092c5f0b12 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224508 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32f0: deep sleep in S0Alexandru M Stan2014-10-011-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Enabled deep sleeping during S0. This was previously inhibited by SLEEP_MASK_AP_RUN but the new config option (CONFIG_LOW_POWER_S0) will ignore it. SPI needed a sleep mask, it essentially gets enabled and disabled whenever the CS changes. Warning: waking up when the CS falls takes a little time, if the AP sends fast data before the 48MHz clock is enabled characters will get corrupted; leave about 30uS time for the clock to start. CQ-DEPEND=CL:219997 CQ-DEPEND=CL:220243 CQ-DEPEND=CL:220461 BUG=chrome-os-partner:32223 BRANCH=none TEST=load onto pinky, boot the AP(S0), use idlestats command to verify that we are going into deep sleep (STOP mode). Verify that everything works normally during S0(SPI, keyboard, anything that requires the EC to wakeup). Change-Id: I81c4fa472332f1ad8ad93301089a99dcdb108948 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219555 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* stm32/spi: Reset peripheral after every packetAlexandru M Stan2014-09-251-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | RX DMA seems to get misaligned sometimes yielding to extra bytes before the first byte on the wire. in_msg=[00 00 00 03 f4 09 00 00 ...] ^ real first byte To fix this we want to reset and reinit the SPI peripheral after every packet, in the same place where setup_for_transaction() is called. This bug applies to the STM32F0 line but resetting the peripheral on other STM32 ECs should not break anything. BUG=chrome-os-partner:31390 TEST=On STM32F0: ap# cd /sys/class/power_supply/sbs-20-000b/; while true; do grep "" * >/dev/null 2>&1; done You should not see "SPI rx bad data" with in_msg packets that have extra bytes in the beggining. Wait though, it might take up to a few minutes for stuff to break. BRANCH=None Change-Id: If9ab93c5c9040a2c7bda33d7cc990603f1121f3f Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217527 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32/spi: Print packet on bad datastabilize-6297.BAlexandru M Stan2014-09-231-0/+7
| | | | | | | | | | | | | | | | | Just after a bad data error the EC will print the packet(pretty much the whole thing): in_msg=[02 00 0f 03 f4 09 00 00 ] I found it very helpful when debugging SPI TX/RX to know what the EC sees. BUG=chrome-os-partner:31390 TEST=Load spidev and send the EC bytes manually(malformed packets) BRANCH=None Change-Id: I037ab909076dc454379040e2e927dc6a0b5c5ea9 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/218442 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* STM32F0 TX FIFO FixesAlexandru M Stan2014-09-111-17/+75
| | | | | | | | | | | | | | | | | | | | | | | | | Whenever we're sending raw status bytes from the EC(while the we're not DMAing) the bytes kinda get garbled, and not get sent in the right order. Sometimes we want the last byte sent to keep repeating, the problem is that it doesn't. Seems like the tx fifo doesn't play nice with the DMA. The way we fix this is by sending bytes 4 times, effectively bypassing the TX fifo. Protocol v2 was not fixed yet. It just displays a warning if one tries to use it on F0. BUG=chrome-os-partner:31390 BRANCH=None TEST=ectool version should work in the most recent kernel(with the v3 protocol version). spidev/python "s.transfer("\xdc\x02\x00\xde"+"\x00"*100)" should return a deterministic packet(the only variation between calls should be the number of \xfa recieved(40 vs 41 or so)). "flashrom -p ec -l /tmp/layout.txt -i rw:/tmp/rw.bin -w -V" now works properly. Change-Id: Ia2772277428bd45013f5721a6bedab13d0591423 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217083 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* STM32F0 SPI Fixes: 4x Dummy BytesAlexandru M Stan2014-08-141-2/+6
| | | | | | | | | | | | | | | | | | | | Seems like STM32_SPI_CR2_FRXTH from 5d208b99(STM32F0 SPI Fixes) was not enough to "disable" RX FIFO from the F0 series. There were still a few bytes stuck in the FIFO just after a command with a long sequence of 00 bytes. This increases the dummy bytes read just before a DMA transfer to 4(size of the FIFO). BUG=none BRANCH=none TEST=Veyron with the new EC should survive the AP booting. ectool version will work right away after boot. This change should not affect other STM32 chips because reading dummy bytes from an empty register is essentially a NOP. Change-Id: I812208622a75ecce82433eb6c12595fee3c1428b Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/212297 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* STM32F0 SPI FixesAlexandru M Stan2014-08-081-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The STM32F0 has a fancier SPI than the L1 series we've been using so far. Notably it supports 16 bit data packing. This mode is activated automatically by reading/writing to the SPI_DR register as 16 bits. We do not want this feature since we only do 8 bit operations. This change prevents a misalignment of the data where the MCU thinks it's doing 16 bit transfers and we want 8 bit transfers. Another unwanted feature is the FIFO. We rely on DMA and some buffers instead. Keeping the FIFO enabled causes extra characters. The way this patch disables the fifo is by changing the FIFO reception threshold to only 1 byte (which is the same behavior that L1 has with no FIFO). Setting the FRXTH bit on the L1 chips should not affect anything as that area of the register is reserved. BUG=none BRANCH=none TEST=Try SPI on both STM32L1xx(preexisting support, should not be broken) and STM32F0(new support/veyron) Change-Id: I90dc6bb8a82881e70058443591acaebc44ba982b Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/211476 Reviewed-by: Doug Anderson <dianders@chromium.org>
* stm32 spi: postpone the RX DMA setup if handler is still using buffer.Louis Yung-Chieh Lo2014-07-081-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | | (cherry-pick back to ToT) If the AP de-asserts the SPI NSS pin while host command handler is still processing the command, we would delay the Rx DMA setup later. If this case happens, the pending result of handler will be dropped. BUG=chrome-os-partner:28979 BRANCH=tot,nyan TEST=build and play around on big. Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/204427 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 4be73492817f3f6c24ece75fed33eb956c0038b8) Change-Id: Ie2a6550696760eadad3b0d6e3a4e56a2b29abdda Original-Change-Id: I371a2a0b96b1ee0602be91338bd53d13f6abbd2e Reviewed-on: https://chromium-review.googlesource.com/206922 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org>
* stm32: spi: read spi->dr into a dummy variableYen Lin2014-07-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry-pick back to ToT) In setup_for_transaction(), read spi->dr into a dummy variable instead of into in_msg[0]. Since in_msg[0] is an alias for a command's port number, this will prevent a command's port number from being over-written if spi transaction is terminated early while a command is still in progress. BUG=chrome-os-partner:28979 BRANCH=nyan TEST=passed factory_test.reboot2 test for >1000 cycles Signed-off-by: Yen Lin <yelin@nvidia.com> Reviewed-on: https://chromium-review.googlesource.com/204355 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 2b043665850f7c74cd6a4a7f24d7a18b01b378ac) Change-Id: Ia412fadcd7621f45bbb096771615ce75fe445592 Oiginal-Change-Id: I308ea954d6242fce5b3a70a14660767ac88d8242 Reviewed-on: https://chromium-review.googlesource.com/206920 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org>
* stm32: move spi init to HOOK_CHIPSET_PRE_INIT.Louis Yung-Chieh Lo2014-07-021-1/+1
| | | | | | | | | | | | | | | The SPI init should run before we power up AP. Otherwise, the AP would try to talk to EC before the EC SPI is ready. This could fail the first SPI transcation. BUG=chrome-os-partner:30083 BRANCH=Tot,nyan TEST=build and run on Nyan only. Change-Id: Ie40ba5210c49446c94c01d697aa66568730de83f Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/206181 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Add cprints() and ccprints()Vic Yang2014-05-211-3/+3
| | | | | | | | | | | | | | | | | | | | | Our code base contains a lot of debug messages in this pattern: CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n") The strings are taking up spaces in the EC binaries, so let's refactor this by adding cprints() and ccprints(). cprints() is just like cprintf(), except that it adds the brackets and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...) This saves us hundreds of bytes in EC binaries. BUG=chromium:374575 TEST=Build and check flash size BRANCH=None Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/200490 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: Re-enable spi transfers after a sysjumpRandall Spangler2014-05-091-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If we sysjump to EC-RW, that sets enabled=0. enabled is only set back to 1 when the chipset resumes. But on an AP-requested sysjump, the chipset is already on, and so the resume hook never gets called. So, in spi init, check if the AP is already on. If it is, enable spi transfers right away. This probably also affects Pit/Pi. That may need an additional fix in power/gaia.c, if it returns an incorrect chipset state after a sysjump (I didn't test that.) BUG=chrome-os-partner:28249 BRANCH=nyan,pit TEST=Power+Refresh boot system with RONormal disabled, so that the AP tells the EC to jump to EC-RW. Confirm EC communication still works after that. Change-Id: I588ef6d841040cf05d5527f645f122d5708b16ad Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198869 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
* cleanup: Remove checkpatch warningsRandall Spangler2013-12-191-2/+2
| | | | | | | | | | | | | | | | This make minor syntactic changes and renames some camel-cased symbols to keep checkpatch from complaining. The goal is to reduce the temptation to use 'repo upload --no-verify'. This is a big furball of find/replace, but no functional changes. BUG=chromium:322144 BRANCH=none TEST=build all boards; pass unit tests Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/180495
* cleanup: Update more TODO commentsRandall Spangler2013-11-011-6/+7
| | | | | | | | | | | | | | | Add bug links, reword, or remove as applicable. No code changes, just comments. BUG=chrome-os-partner:18343 BRANCH=none TEST=build all boards; pass unit tests Change-Id: Id55dd530c10091d7ab9d0f942f750168fca793b4 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175326 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Fix a bug that GPIO cannot be set as input on stm32lVic Yang2013-09-041-1/+1
| | | | | | | | | | | | | | | | | GPIO_INPUT is defined as 0, and any GPIO flag cannot be examined against GPIO_INPUT. Change GPIO_INPUT to non-zero value to avoid this. BUG=chrome-os-partner:22275 TEST=On Kirby, set a GPIO to output and pull it low, and then set it back to input. Check it can be pull high externally. TEST=Build all boards. TEST=Boot link and spring. BRANCH=None (unless this bug hits some other boards.) Change-Id: I84b9936c24af538ac59c36129fda27ca879bf9d1 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167190 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Clean up configuring GPIO alternate functionsRandall Spangler2013-08-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GPIO alternate functions used to be configured throughout the code, which made it hard to tell which ones you needed to configure yourself in board.c. It also sometimes (chip/lm4/i2c.c) led to GPIOs being configured as alternate functions even if they weren't used on a given board. With this change, every board has a table in board.c which lists ALL GPIOs which have alternate functions. This is now the only place where alternate functions are configured. Each module then calls gpio_init_module() to set up its GPIOs. This also fixes a bug where gpio_set_flags() ignored most of the flags passed to it (only direction and level were actually used). On stm32f, gpio_set_alternate() does not exist, and pins are configured via direct register writes from board.c. Rather than attempt to change that in the same CL, I've stubbed out gpio_set_alternate() for stm32f, and will fix the register writes in a follow-up CL. BUG=chrome-os-partner:21618 BRANCH=peppy (fixes I2C1 being initialized even though those pins are used for other things) TEST=boot link, falco, pit, spring Change-Id: I40f47025d8f767e0723c6b40c80413af9ba8deba Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/64400
* Clean up SPI state machine and add state codesRandall Spangler2013-08-051-40/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | The old low-level SPI protocol provided no useful information to the host about whether it was ready to receive or not. It also could get stuck waiting to receive data without setting up receive DMA, if the host did two transactions back-to-back. Add a real state machine to the SPI module. Add a range of byte codes the EC can return outside of a response frame, to indicate its current state. If the AP receives one of these codes, it can abort the transaction since it now knows the EC is unable to determine when it can send a response frame. This change is backwards-compatible with current AP firmware and kernel drivers, since those only look for the framing byte and don't care what other bytes are received in the meantime. BUG=chrome-os-partner:20257 BRANCH=none TEST=crosec test; passes at 70us. Change-Id: Ia06109ead3fbc421848e01050f7baf753cbeb16c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/64254 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Host commands don't set the response pointerRandall Spangler2013-08-021-5/+1
| | | | | | | | | | | | | | | | Remove support for allowing host command handlers to set the response pointer. This is just one more thing that can break (and did, on SPI protocol V2). No commands other than the trivial read-memory-map command in host_command.c and flash read made use of this capability, and the savings in performance was negligible. BUG=chrome-os-partner:21576 BRANCH=none TEST=boot pit; still boots Change-Id: I0a9bcf57dbea7155318fc389d7b47d3742a1a00a Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/64236
* pit: Align spi protocol buffers on 32-bit boundaryRandall Spangler2013-07-081-7/+11
| | | | | | | | | | | | | | | Flash writes must be done from 32-bit-aligned source buffers. Force the protcol buffer to be aligned like we do for the lpc interface. BUG=chrome-os-partner:20571 BRANCH=none TEST=ectool flashread 0x1f800 0x800 /tmp/foo ectool flasherase 0x1f800 0x800 ectool flashwrite 0x1f800 /tmp/foo Change-Id: Icaa3259bcbc36be49345da5e19ad8a0790b73923 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60892
* Move protocol v2 constants to ec_commands.hRandall Spangler2013-07-031-114/+90
| | | | | | | | | | | | | | | | These constants are scattered around the various interface implementations and should be in one place. This will also clean up the u-boot side when ec_commands.h is copied there. BUG=chrome-os-partner:20257 BRANCH=none TEST=build link, spring, pit; test 'ectool hello' Change-Id: Ib1425db00ec8220538d8c5c65107ac9548009516 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60810 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* Add get-protocol-information commandRandall Spangler2013-07-021-12/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is necessary to support larger packet sizes for host protocol ver.3. The host previously didn't have any way to know how big a packet the EC could accept / respond with (except on LPC, where the size is determined by the I/O window). BUG=chrome-os-partner:20257 BRANCH=none TEST='ectool protoinfo' returns good info; on link, Protocol info: protocol versions: 2 3 max request: 256 bytes max response: 256 bytes flags: 0x00000000 and on pit, Protocol info: protocol versions: 2 3 max request: 544 bytes max response: 544 bytes flags: 0x00000001 Change-Id: Ic1e3831d9b4a96ffbf365c0d09b6023472de39a9 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60703 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* stm32: Clean up DMA register usageRandall Spangler2013-06-271-13/+13
| | | | | | | | | | | | Bitfields are now in registers.h where they belong. BUG=chrome-os-partner:20529 BRANCH=none TEST='crosec test' from u-boot still works Change-Id: I726550a32b61111c906c1b10c628c5e47eff74fb Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60179
* stm32: Clean up SPI register usageRandall Spangler2013-06-271-20/+7
| | | | | | | | | | | | | Bitfields are now in registers.h where they belong. BUG=chrome-os-partner:20529 BRANCH=none TEST='crosec test' from u-boot still works Change-Id: If0d79a66a90665c8ea336a006d76ccbc00a927ec Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/60139 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Clean up DMA module and interface.Randall Spangler2013-06-261-5/+5
| | | | | | | | | | | | | | | | | | | | | | | Explicitly use enum for dma_channel, instead of ints (since channel is 1-based in the docs and 0-based in the enum). Add enum values for other channels like USART. Use volatile structs instead of typecasting through REG32(). Other assorted code cleanup. Remove DMA2 partial support, since neither STM32F100R8 nor STM32L151x has hardware support for it and it cluttered the code. No functional changes. BUG=chrome-os-partner:20485 BRANCH=none TEST=from pit root shell, 'ectool version' still works Change-Id: Ifdd62fb287c608a684ba8fa16934dfcab83ee609 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/59949
* pit: Disable SPI output when AP is suspendedRandall Spangler2013-06-201-0/+2
| | | | | | | | | | | | | | | This fixes the problem where the EC consumes too much power during suspend. BUG=chrome-os-partner:20223 BRANCH=none TEST=from root shell, 'powerd_suspend'. 1.8V_MICOM should not go up. after resume, 'ectool hello' should still work. Change-Id: I93b781e96bea633419e923a83f1f6d7300ae8c54 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/59474 Reviewed-by: Derek Basehore <dbasehore@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* Refactor host command interface to support version 3 packetsRandall Spangler2013-06-201-2/+100
| | | | | | | | | | | | | | | | | | | | | | | | | This will fix EC flash commands on pit, once the host side (u-boot and cros_ec driver) are upgraded to match. This change is backwards-compatible the EC still supports the existing version 2 protocols for talking to existing AP/kernel/ectool. Once the AP-side supports version 3 for SPI (and existing systems are upgraded), we will remove older SPI support since we haven't shipped a product which uses SPI. BUG=chrome-os-partner:20257 BRANCH=none TEST=disable cros_ec driver support in ectool; 'ectool hello' works on link And with an old ectool which predates this CL, 'ectool hello' also works. On pit, from u-boot prompt, 'crosec test' and 'crosec version' work, and keyboard works. Change-Id: I01f193e316e9aa442fe50d632dc8a4681723e282 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58908 Reviewed-by: Simon Glass <sjg@chromium.org> Commit-Queue: Doug Anderson <dianders@chromium.org>
* Set SPI lines to inputs when AP is offRandall Spangler2013-05-161-2/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When AP is off, turn off pullup on NSS, and set MISO to an input so the SPI module won't drive it high if the last sent bit was a 1. This reduces leakage when the AP is off. This patch also fixes a bug where gpio_set_alternate_function() set the wrong pins to normal-mode when func=-1; that didn't hit anything else because that functionality wasn't used on STM32 until now. BUG=chrome-os-partner:19304 BRANCH=none TEST=boot pit On EC console, with AP on, 'rw 0x40020000' returns read 0x40020000 = 0x6569aa20 <- must have 0x____aa__ Then 'apshutdown' and 'rw 0x40020000' returns read 0x40020000 = 0x65690020 <- must have 0x____00__ The 'power on' and AP turns back on. At u-boot prompt, 'sspi 2:0 256 9f00000000' returns FDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFEEC010001 (some number of 0xFD's followed by FEEC...) This shows SPI functionality is restored when AP is powered back on, and not just at init time. Change-Id: Ia3cd3e0bc222dc663d635509918fa3d383fd7971 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/51182 Reviewed-by: Simon Glass <sjg@chromium.org>
* spi: Fix OOBE in bounds-checking the replyDoug Anderson2013-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | There was an off-by-one error in bounds checking the reply. You could trigger it with pydevi2c with: >>> tps = I2CDevice(20, 0x48, force=True) >>> tps.Get(0, 249) The EC would show: ASSERTION FAILURE 'msg_len < sizeof(out_msg)' in reply() at chip/stm32/spi.c:184 BUG=chrome-os-partner:18778 BRANCH=none TEST=Run the above commands and see no error. Change-Id: I9789405a9d70c5dc3fa237504fea8f46a139386c Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50254 Reviewed-by: Simon Glass <sjg@chromium.org>
* Fix and enable SPI for pitRandall Spangler2013-05-071-51/+29
| | | | | | | | | | | | | | | | | | | | | | | | | I've simplified the SPI module, since we only ever use SPI1 (and there were already a number of places which assumed this was true). Somewhere along the way I fixed a number of problems keeping the code from compiling and working on STM32L. The code isn't currently used anywhere else, but should still work there (that is, I don't think I broke it working on STM32F if you re-enable it on some STM32F platform). BUG=chrome-os-partner:19073 BRANCH=none TEST=from u-boot console, sspi 2:0 64 9f0000 u-boot prints: FDFDFDFDFDFDFDFD ec prints: [193.740912 HC 0x9f][193.741141 HC err 1] [sjg: gpio optimization back in for now] [dianders: add comment as rspangler requested; update SOBs] Change-Id: Ib9419403e4e44dadc1f17681e48401882cb49175 Signed-off-by: Randall Spangler <rspangler@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/49684
* Clean up daisy GPIO and SPI initRandall Spangler2013-04-081-1/+4
| | | | | | | | | | | | | | | Much of the board init duplicated stuff already done in gpio init, so remove it. Powering the SPI module should be done in spi.c, not board.c. BUG=chrome-os-partner:18343 BRANCH=none TEST=build all platforms; boot EC on daisy Change-Id: I9a99eeeb971ebbf7de5b9c0548153684fbb7fff6 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/47469 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* stm32: Export DMA memory size optionVic Yang2012-09-261-2/+18
| | | | | | | | | | | | | | We need different memory size configuration in different application. Let's export the memory size option to DMA function parameters. BUG=chrome-os-partner:14316 TEST=Boot on snow. Check I2C host command works. BRANCH=none Change-Id: I30481ddf86a1526d517961e009898642ecdd649a Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/33981 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* spi: Rewrite driver for new protocol, better performanceSimon Glass2012-09-171-124/+203
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old spi driver has atrophied in various ways. It doesn't support the new protocol and does not build either. Rewrite the driver to: - Use dma for reception (rather than just reception) - This makes message reception more robust and allows us to process the new multi-byte commands - Add timeouts for rx and tx so that we don't wait forever - Increase buffer sizes to deal with new larger messages - Always send a preamble byte regardless of SPI clock speed (previously above 10MHz we sometimes miss this) - Use the NSS line to delineate transactions. When it drops, a transaction is starting. When it rises the transaction is immediately terminates regardless of state. This keeps the AP and EC in sync even in the event of timeouts, bus errors and other oddities. - Implement the new protocol which has a checksum, version byte, etc - Set up tx dma in advance and kick it when ready, thus ensuring that a message body is always attached immediately after the preamble - Use the new host_cmd_handle_args structure, which makes things much easier for us, since we don't need globals, and can use the send_response handler to know when a slow command is complete. - Handle the new type of 'slow' commands properly BUG=chrome-os-partner:10533 TEST=manual build and boot to kernel on snow Change-Id: I11767d1a6f045a86f6c9a0b4b1e943b660e4da33 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32076 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* host_command: Add send_result() to the arg structureSimon Glass2012-07-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a bit odd that the drivers package up a command to be processed by host_command, but then host_command calls a global function to pass the response back. This adds ambiguity in the host_send_response() implementations as to whether the command being responded to really is using the same buffers that the driver set up. Add a function pointer to the command, and have host_command call that. Add status to the args structure also, which removes some of the special case logic for error handling. BUG=chrome-os-partner:11317 TEST=manual and a bit ad-hoc: (note, this testing is not completed yet) Check that snow and link still process commands correctly over I2C from U-Boot. At this stage only the old interface is supported. SMDK5250 # mkbp test Old interface: New interface: Version 0: ec_command() returned error Test failed with error -1 SMDK5250 # Change-Id: I816738150bce3f8d78e7cd32abf361621aa12312 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/28154 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Revert "host_command: Add send_result() to the arg structure"Randall Spangler2012-07-221-7/+0
| | | | | | | | | | | | This reverts commit 18db93b25b05c871826fd1853a33a560e64ed247 Breaks link checksums. Change-Id: Ieeb278b7d4da0600bdc9ced1476b67f23abce1a1 Reviewed-on: https://gerrit.chromium.org/gerrit/28136 Commit-Ready: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* host_command: Add send_result() to the arg structureSimon Glass2012-07-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a bit odd that the drivers package up a command to be processed by host_command, but then host_command calls a global function to pass the response back. This adds ambiguity in the host_send_response() implementations as to whether the command being responded to really is using the same buffers that the driver set up. Add a function pointer to the command, and have host_command call that. Add status to the args structure also, which removes some of the special case logic for error handling. BUG=chrome-os-partner:11317 TEST=manual and a bit ad-hoc: (note, this testing is not completed yet) Check that snow and link still process commands correctly over I2C from U-Boot. At this stage only the old interface is supported. SMDK5250 # mkbp test Old interface: New interface: Version 0: ec_command() returned error Test failed with error -1 SMDK5250 # Change-Id: Ic4afdcd7689666cc0f6af228abc6cffe41b0fcbf Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27468
* Pass maximum size of response buffer in via host command handler argsRandall Spangler2012-07-121-0/+1
| | | | | | | | | BUG=chrome-os-partner:11275 TEST=from u-boot prompt, 'mkbp hash' Change-Id: I4cf37acfdd8e4edfe2cb6259b0fc6d0860ef0f79 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27225
* Move host_cmd_handler_args farther up the call chainRandall Spangler2012-07-111-4/+25
| | | | | | | | | | | | | This is necessary for an imminent change which passes version data from the host bus (LPC/I2C/SPI) into the host command handler. BUG=chrome-os-partner:11275 TEST=from u-boot prompt, 'mkbp hash' Change-Id: If34d0d7c6dc320ad5632becf512c30900fd61aca Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27190 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* stm32: Fix up SPI driver to use host_command interfaceSimon Glass2012-07-021-18/+16
| | | | | | | | | | | | | | | | | | | This driver was not refactored when the host_command changes were made, although i2c was. Tidy this up. SPI requests the command response immediately rather than going through the task queue, since otherwise a response may take long enough that the SPI master misses it altogether. BUG=chrome-os-partner:10533 TEST=manual: build and boot on snow; In U-Boot: > sspi 4:0 240 20 See that it gets key messages back now Change-Id: Ia2c24d4c8876fefedad4c02802f77e50d7159d03 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/25982
* Initial Snow board portDavid Hendricks2012-05-041-1/+1
| | | | | | | | | | | | | | | Mostly stolen from Daisy. Notable differences: - No SYSCFGEN required for external interrupts ? - No GPIO H bank on STM32F100, OSC_IN and OSC_OUT are not available --> CODEC_INT and ENTERING_RW signals are missing BUG=None TEST=Tested on ADV2/Snow, able to see EC serialconsole Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I955e2ff180d064294d67b630ae2ee6cfcfe52ab9
* daisy: Re-introduce SPI protocol supportSimon Glass2012-05-031-11/+52
| | | | | | | | | | | | | | The changes in the message protocol break SPI support, so re-introduce these, this time in the driver itself. We add the concept of an option preamble in the message, a length and a trailing byte. BUG=chrome-os-partner:9426 TEST=run U-Boot, see that keyboard works correctly now. Change-Id: I83b4af7e3745b935ffafcd9e2f521fce77e3bc6e Signed-off-by: Simon Glass <sjg@chromium.org>
* remove deprecated stm32-based boardsVincent Palatin2012-05-021-1/+1
| | | | | | | | | | | We no longer support ADV EVT0 board and Discovery reference design. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=None TEST=make BOARD=daisy && make BOARD=link Change-Id: I7eb81e5271c070b17f018ac9c14491f1804c0e08
* introducing chip variant for stm32 family [1/3]Vincent Palatin2012-05-011-0/+188
just rename STM32L to STM32. Most of the STM32L15x code is common with STM32F1xx. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=chrome-os-partner:9057 TEST=make BOARD=daisy ; make BOARD=adv ; make BOARD=discovery Change-Id: I819eff5fcd23deff57f5f6dedcf37e6c421b96c2
View Lorry Controller Status