summaryrefslogtreecommitdiff
path: root/include/task.h
Commit message (Collapse)AuthorAgeFilesLines
* samus: pd: fix potential junk at end of tx transmissionstabilize-6670.BAlec Berg2015-01-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix potential junk at end of PD TX transmit by adding to the DMA transmit complete interrupt a blocking wait for SPI to finish and then immediately disable SPI clock. This means we block in an interrupt function for approximately 45us at the end of every transmit. But, this is the highest priority thing going on anyway. Note, there is still a potential for junk if both ports are transmitting at the same time and finish very close to the same time. BUG=chrome-os-partner:34600 BRANCH=samus TEST=load onto samus and test communications with zinger. tested specifically with an old zinger CL, https://chromium-review.googlesource.com/#/c/226118/11, which watchdogs when samus has junk at end of transmit. Tested without this CL and verified we could never successfully flash zinger over PD due to this watchdog and verified on scope presence of junk. Then tested with this change and was able to successfully flash zinger using ectool on both ports in both polarities. Change-Id: If0cd9ab0551d36a7d7dc10232b6476dd56735972 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239244 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32f: Add DMA interrupt handlers for channel 1 to 3Vic Yang2014-10-211-1/+2
| | | | | | | | | | | | | | | | | | We already have interrupt handlers for channel 4 to 7. We need channel 3 for the new Ryu boards. Add the handlers for channel 1 to 3. Also, instead of copy-pasting interrupt handlers, define a macro and declare interrupt handlers with it. BRANCH=None BUG=chrome-os-partner:32660 TEST=make buildall TEST=Check PD communication on the new Ryu board (with other CLs to enable the new boards.) Change-Id: I51d6bd16739f31a7efbeb4ec19bb91a1546fe21d Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224175 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* IRQ list support for enabling specific IRQs without common runtimeVic Yang2014-06-191-1/+7
| | | | | | | | | | | | | | | | | | | This adds back DECLARE_IRQ() support when building without common runtime. With this, we can enable only a subset of IRQs and avoid linking in other unused IRQ handlers. Note that after this change, all boards without common runtime need to have a ec.irqlist file. BUG=None TEST=Build Keyborg and check it still works. TEST=make buildall BRANCH=None Change-Id: If68062a803b9a78f383027a1625cf99eb3370d3f Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/203264 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Keep IRQ_HANDLER macro when building without common runtimestabilize-5944.Bstabilize-5943.BVic Yang2014-06-101-0/+1
| | | | | | | | | | | | | | | | | | | | Without common runtime, we need to use IRQ_HANDLER to define IRQ handlers. Previously IRQ_HANDLER is only implemented in irq_handler.h which is not included by task.h when building without common runtime. This causes problem when we want to use code that includes task.h and uses IRQ. By adding IRQ_HANDLER to task.h, we don't need to include irq_handler.h in any case, and thus avoid that problem. BUG=None TEST=make buildall TEST=include task.h instead of irq_handler.h. Check Keyborg still builds. BRANCH=None Change-Id: I1213506132025fc656630565f58686b9e7de940c Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/203084 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* cortex-m: store FPU regs on context switchAlec Berg2014-04-181-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added storing of FPU regs on context switches when CONFIG_FPU is defined. On context switches, EXC_RETURN[4] is checked in order to tell which tasks have used floating point and which have not. The FPU regs are only stored on task stacks for tasks that use the floating point. Tasks that use floating point will therefore require roughly an additional 128 bytes of stack space, and context switches will take about 32 clock cycles longer for each task involved in the switch that uses FP. For tasks that don't use floating point, the stack usage actually decreases by 64 bytes because previously we were reserving stack space for FPU regs S0-S15 on every context switch for every task, even though we weren't doing anything with them. If a task only uses the FPU for a brief window, it can call task_clear_fp_used() in order to clear the FP used bit so that context switches using that task will not backup FP regs anymore. BUG=chrome-os-partner:27971 BRANCH=none TEST=Tested on glimmer and peppy. Added the following code, which uses the FPU in both the hooks task and the console task. Note, I tested this for a handful of registers, notably registers in the group s0-s15 which are backed up by lazy stacking, and registers in the group s16-s31 which are backed up manually. float dummy = 2.0f; static void hook_fpu(void) { union { float f; int i; } tmp; /* do a dummy FP calculation to set CONTROL.FPCA high. */ dummy = 2.3f*7.8f; /* read and print FP reg. */ asm volatile("vmov %0, s29" : "=r"(tmp.f)); ccprintf("Hook float 0x%08x\n", tmp.i); /* write FP reg. */ tmp.i = 0x1234; asm volatile("vmov s29, %0" : : "r"(tmp.f)); } DECLARE_HOOK(HOOK_SECOND, hook_fpu, HOOK_PRIO_DEFAULT); static int command_fpu_test(int argc, char **argv) { union { float f; int i; } tmp; /* do a dummy FP calculation to set CONTROL.FPCA high. */ dummy = 2.7f*7.8f; /* read and print FP reg. */ asm volatile("vmov %0, s29" : "=r"(tmp.f)); ccprintf("Console float 0x%08x\n", tmp.i); if (argc == 2) { char *e; tmp.i = strtoi(argv[1], &e, 0); if (*e) return EC_ERROR_PARAM1; /* write FP reg. */ asm volatile("vmov s29, %0" : : "r"(tmp.f)); } else { task_clear_fp_used(); } return EC_SUCCESS; } DECLARE_CONSOLE_COMMAND(fputest, command_fpu_test, "", "", NULL); When you call fputest 5 from EC console before this CL, then on the next HOOK_SECOND, the value of register s29 is 5, instead of 0x1234 because register s29 is not saved on context switches: Hook float 0x00001234 > fputest 5 Console float 0x00001234 Hook float 0x00000005 When this CL is in use, the register holds the correct value for each task: Hook float 0x00001234 > fputest 5 Console float 0x00001234 Hook float 0x00001234 > fputest Console float 0x00000005 Hook float 0x00001234 Change-Id: Ifb1b5cbf1c6fc9193f165f8d69c96443b35bf981 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/194949 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* lm4: Use a special task event for ADC conversionsChromeOS Developer2014-03-261-1/+3
| | | | | | | | | | | | | | | | | This prevents other task events from continuing the ADC conversion prematurely; potentially leading to a panic if the conversion interrupt occurs after the ADC has been powered down. BUG=chrome-os-partner:26919 BRANCH=rambi TEST=Perform ADC conversions while running a deferred function calling itself on a 10mSec delay. Verify no panics after ~6 hours. Change-Id: Ic3894849c154b3f058e812b2da816e7cffb12cbf Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/191302 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cortex-m: Add task_wait_event_mask() helper functionChromeOS Developer2014-03-261-1/+20
| | | | | | | | | | | | | BUG=chrome-os-partner:27180 BRANCH=rambi TEST=Tested indirectly via subsequent patches to use this call in the adc and i2c handlers for the lm4. Change-Id: I53501fdf47d606ea6c7705facb66e945e25d9745 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/191300 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* make the common runtime optionalVincent Palatin2014-03-221-0/+4
| | | | | | | | | | | | | | | | | | | | | In order to achieve really tiny firmwares, make our runtime (tasks, hooks, muxed timers, GPIO abstraction ...) optional. Add 2 new build options for it : CONFIG_COMMON_RUNTIME and CONFIG_COMMON_GPIO which are enabled by default, and ensure all the source files are built according to the right configuration variable. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=make buildall build a minimal board with no runtime. Change-Id: Icb621cbe0a75b3a320cb53c3267d6e578cd3c32f Reviewed-on: https://chromium-review.googlesource.com/189403 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* force the compiler to use a valid register allocation for irq handlersVincent Palatin2014-03-111-26/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are calling the re-scheduling routine at the end of an irq handling routine, we need to ensure that the high registers are not currently saved on the system stack. On Cortex-M3/M4, the compiler is normally doing tail-call optimization there and behaving properly, but this fixes the fact that insanely large interrupt handling routines where sometimes not compile and not running properly (aka issue 24515). This also prepares for one more core-specific DECLARE_IRQ routine on Cortex-M0. Note: now on, the IRQ handling routines should no longer be "static". Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:24515 TEST=make -j buildall revert the workaround for 24515, see the issue happening only without this CL. Change-Id: Ic419369231925568df05815fd079ed191a5446db Reviewed-on: https://chromium-review.googlesource.com/189153 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* emulator: Move trace dump to a separate moduleVic (Chun-Ju) Yang2014-01-221-0/+5
| | | | | | | | | | | | | | | The implementation of trace dump has little to do with task scheduling, so we should move it to a separate module for cleaner code. This requires exposing some emulator-specific task info, as defined in host_task.h. BUG=chrome-os-partner:19235 TEST=Pass all tests BRANCH=None Change-Id: Iba9bc0794a4e1dd4ddb92b98345162b398fa6a8d Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/183238
* ite: Port OS layer to Andestar v3m architectureVincent Palatin2013-12-101-0/+9
| | | | | | | | | | | | | | | | | This will be used to support ITE IT8380 chip which contains an Andes N801 core. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:23574 TEST=make BOARD=it8380dev Change-Id: I91f9380c51c7712aa6a6418223a11551ab0091ce Reviewed-on: https://chromium-review.googlesource.com/175480 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* Standardize concatenation macrosRandall Spangler2013-07-241-5/+4
| | | | | | | | | | | | | | | | | | To create a token by concatenating already-defined macros and new text, it's necessary to use multiple levels of macro. We'd already done that in several places in the code such as STM32_CAT; this now standardizes it into a single place. BUG=chrome-os-partner:18343 BRANCH=none TEST=Build all platforms; examine ec.RO.map to see that irq_*_handler and prio_* symbols evaluated the same as before. (Other macro evaluations would simply fail to compile if they were incorrect, since the concatenated tokens wouldn't fully expand.) Change-Id: Ic9bf11d27881a84507fe7b6096dab6217c6c6dc7 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/63231 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* link: Fix overflow in hibernate time calculationRandall Spangler2012-11-011-0/+3
| | | | | | | | | | | | | | | | | | The time out value passed to task_wait_event() is signed 32-bit and thus waiting for 24 hours will cause overflow. Limit max wait time. BUG=chrome-os-partner:15797 BRANCH=link TEST=Disconnect AC, shut down system, and close lid. From ec console, do 'hibdelay 8000' and then wait 2.5 hours. EC should have hibernated. (8000 is more than twice the max time for task_wait_event()) Change-Id: I5fa505554182e8bad6399c12a382ff71bb123d8f Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/37095 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Clean up core routines - cpu, task, watchdogRandall Spangler2012-10-291-58/+113
| | | | | | | | | | | | No functional changes. BUG=chrome-os-partner:15579 BRANCH=none TEST=boot system Change-Id: I55cf9c60e92177fd441614a8f9fce2d3acca3d0e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36706
* Prevent I2C interrupts from consuming pending task eventsBill Richardson2012-09-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This manifested as the lightbar task missing transitions between CPU states. The underlying cause was that when a task talks over the I2C bus, the I2C communication was using the task scheduler to wait for an interrupt to signal completed I2C traffic without blocking the other threads, but while doing so it was not preserving pending events. This CL seems to fix it. BUG=chrome-os-partner:12431 BRANCH=all TEST=manual The original bug is tricky to reproduce without adding some delay to the I2C task code, but you can do it. Boot the CPU, then from the EC console repeatedly alternate these two commands: lightbar seq s0 lightbar seq s3 You should see the lightbar pattern turn off and on, but occasionally you'll type the command and the EC won't change the pattern. With this change applied, it should *always* work. Change-Id: Ie6819a4a36162a8760455c71c41ab8a468656af1 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/33805 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Track current task directly instead of computing from stack pointerRandall Spangler2012-09-091-8/+1
| | | | | | | | | | | | | | | This is a precursor to supporting task-specific task sizes. I've benchmarked this vs. the current stack pointer method; no measurable performance difference. BUG=chrome-os-partner:13814 TEST=boot EC; taskinfo; if it boots and doesn't print garbage, it worked BRANCH=all Change-Id: Ia326c3ab499ac03cce78dbacaa52f735601a171e Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/32603 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* usleep() chains to udelay() if called before task_start()Randall Spangler2012-05-291-6/+10
| | | | | | | | | | | ...so I can use usleep() for eeprom delays in the CL coming next... Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:10200 TEST=if it boots, it worked Change-Id: I564578f24452a4ac39abe79ff28cfff4b665ad2f
* Watchdog fixesRandall Spangler2012-04-251-0/+9
| | | | | | | | | | | | | | | | | | 1) When frequency changes, reload the watchdog timer right away, or it may expire before the next reload. (Only matters when re-enabling the PLL.) 2) Split out the timer/task debug output used by the watchdog into their own routines, instead of assuming it's safe to call the command handlers. Also make the flushes in those print routines safe to call from interrupt level. Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=none TEST=waitms 1500; should print task dump again Change-Id: I07e0ed24a526ae499566dab0bbeb0f5755cd5be6
* Implement task profilingRandall Spangler2012-04-241-1/+13
| | | | | | | | | | | | | | Also tracks the distribution of IRQs, so we can see what's triggering interrupts. Task profiling is optional, enabled via CONFIG_TASK_PROFILING. Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:7464 TEST=taskinfo Change-Id: I266f2b49bff9648cda446210d5a302b460fec244
* Re-enable watchdog in watchdog_reload()Randall Spangler2012-04-121-0/+9
| | | | | | | | | | | | | | | | Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:8971 TEST=manual waitms 1500 (see watchdog trace) waitms 1500 (should see watchdog trace again) waitms 3000 (should see trace, then system should reboot) Change-Id: Ieb5009d7a7bc9e1ed795e58efb0cb44a1eeb2706
* Change task messages to eventsRandall Spangler2012-04-061-47/+49
| | | | | | | | | | | | | Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:7461 TEST=manual make BOARD={bds,link,daisy} make tests flash link system and make sure it boots Change-Id: I1241a1895c083e387e38ddab01ac346ca4474eb9
* Support warm reboot from one EC image to another.Randall Spangler2012-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | This is necessary at init-time for verified boot to jump from RO to one of the RW images. It's also used by factory EC update to update one image and then jump to the updated image to finish the update. In this case, the x86 does NOT reboot. Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:8449 TEST=manual 1) power on x86 and log in 2) sysjump a --> system is in a; x86 has not rebooted 3) sysjump ro --> system is back in RO; x86 has not rebooted 4) reboot -> system is in RO; x86 HAS rebooted Change-Id: I9dbadcf9775e146a0718abfd4ee0758b65350a87
* FPU controlVic Yang2012-02-161-0/+7
| | | | | | | | | | | | | Implement enable_fpu() and disable_fpu(). enable_fpu() disables interrupt and then enables FPU. disable_fpu() disables FPU and enables interrupt. Also added a CONFIG_FPU flag. BUG=chrome-os-partner:7920 TEST=none Change-Id: I2d71f396d9c7d7ac4a6a2d525f3d86f8aae87521 Signed-off-by: Vic Yang <victoryang@chromium.org>
* expand properly the IRQ number for IRQ declaration macroVincent Palatin2012-01-301-1/+1
| | | | | | | | | | | | Expand the macros before building the priority variable name in order to ensure we have a valid name. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=None TEST=check manually preprocessor expansion for several combinations. Change-Id: I926821d42c966ac674e7d24254c9f22779f93ca2
* Go back to SoC independant IRQ vectors declarationVincent Palatin2012-01-251-6/+5
| | | | | | | | | | | | | | | | | Preparatory work to introduce a second SoC : 1/5 Instead of putting hardcoded IRQ SoC name in the vector table, upgrade the DECLARE_IRQ macro to expand its argument. Also add a parameter to set the size of the NVIC table to save flash memory. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=None TEST=run EC on BDS and see timer IRQs firing. Change-Id: I44fefdabdd37d756492a71f24554979c72c1b50f
* Initial mutex implementationVincent Palatin2012-01-251-0/+15
| | | | | | | | | | | | | | | | | | | They are designed to protect shared hardware resources (e.g. I2C controller). Please refrain using them as a general purpose synchronization primitive for the tasks to avoid unintended slippery effects (e.g. priority inversion), use the provided message-passing functions instead for that purpose. The mutex variable (ie the "struct mutex") should be initially filled with 0, but this is the default compiler behavior if you declare it as a global variable. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BUG=None TEST=make qemu-tests Change-Id: I328f7eadf5257560944dbbbeda0b99d5b24520e8
* Handle all GPIO IRQs. Interrupts no longer enabled by default.Randall Spangler2012-01-171-3/+3
| | | | | | | | | Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:7456 TEST=if it runs, it works Change-Id: Ib82afab7d53203af31eefc9887feb98679266ac1
* Use #defined constants for IRQ namesRandall Spangler2011-12-191-3/+4
| | | | | | | | | Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=none TEST=none Change-Id: If07ac671cef6b9d0e9fe0a96bf04455a3d2626ff
* Add IRQ constants, and task functions to enable/disable/trigger IRQs.Randall Spangler2011-12-121-6/+20
| | | | | | | | | | | | | The constants don't work with the DECLARE_IRQ() macro yet, because it relies on stringizing the IRQ number. Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=none TEST=none Change-Id: Ie6ddecd79e28c319b095089131579ba994a17da3 (cherry picked from commit e24904644a977f2618f51629cc066b93a3d53595)
* Initial sources import 3/3Vincent Palatin2011-12-071-0/+95
source files mainly done by Vincent. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Change-Id: Ic2d1becd400c9b4b4a14d4a243af1bdf77d9c1e2
View Lorry Controller Status