summaryrefslogtreecommitdiff
path: root/src/cpu/samsung/exynos5420/power.c
AgeCommit message (Collapse)Author
2014-08-26armv7: Move Exynos from 'cpu' to 'soc'.Hung-Te Lin
The Exynos family and most ARM products are SoC, not just CPU. We used to put ARM code in src/cpu to avoid polluting the code base for what was essentially an experiment at the time. Now that it's past the experimental phase and we're going to see more SoCs (including intel/baytrail) in coreboot. Change-Id: I5ea1f822664244edf5f77087bc8018d7c535f81c Reviewed-on: https://chromium-review.googlesource.com/170891 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Ronald Minnich <rminnich@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org> (cherry picked from commit c8bb8fe0b20be37465f93c738d80e7e43033670a) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6739 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-18arm/exynos: Allow releasing UART retention for resume.Hung-Te Lin
The UART / serial console is put in retention state by kernel during suspend / resume path, which caused Coreboot not able to print any messages during resume. Sending values to the padret_uart_opt inside PMU may release UART, but that may also cause unexpected output when kernel is back. However, it's still very helpful when we are debugging suspend/resume inside Coreboot. To get UART message on resume, call wakeup_enable_uart() in boot block or romstage (before console_init). Change-Id: Ib5759cb402c6e018d9dba14fad8b61f6a1b1a265 Reviewed-on: https://chromium-review.googlesource.com/170440 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org> (cherry picked from commit 547fbbfe2eeb6da4e161f36be2caf8099f9eac9b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6649 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-14exynos5: Refactor crazy old U-Boot base address macros awayJulius Werner
All this samsung_get_base_address_of_device_with_a_really_long_name() boilerplate makes my eyes bleed... I think there are so much cleaner ways to do this. Unfortunately changing this ends up touching nearly every Exynos5 file, but I hope you agree that it's worth it (and the sooner we get it over with, the better... I can't bring myself to make another device fit into that ugly scheme). This also removes the redundant EXYNOS5 base address definitions from the 5420 directory when there are EXYNOS5420 ones, to avoid complete confusion. The new scheme tries to use EXYNOS5 for base addresses and exynos5 for types that are common between the two processors, and EXYNOS5420/exynos5420 for things that have changes (although I probably didn't catch all differences). Change-Id: I87e58434490ed55a9bbe743af1f9bf2520dec13f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167579 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: ron minnich <rminnich@chromium.org> (cherry picked from commit 66c87693352c248eec029c1ce83fb295059e6b5b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6632 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-08-12exynos5: Refactor board-specific parts out of USB PHY codeJulius Werner
This patch moves around some of the existing Exynos5 USB 2.0 PHY code to make it cleaner in preparation of the 3.0 PHYs. It moves the VBUS GPIOs (which are completely board-specific) into the mainboard code and makes sure to only initialize PHYs on the boards that actually need them. It also removes the USB 3.0 PLL hack that was needed on Snow from the Pit and Kirby boards (which do not have that PLL anymore). Change-Id: Ia35f47a765acff60481f0907f7448ec4f78e0937 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66887 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit c3b1a8b687b535f4d5ac1b3bd2a4760151698fdb) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6609 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-12-21Pit: graphicsRonald G. Minnich
This includes the new dp code, which is better, and the fimd code, which is changed and improved. We took the chance to remove un-needed files, and also to remove some foolish u-boot habits, but not all of them. That will take time. With these changes we get graphics. Since the only mainboards we have with 16 bit graphics are 5:6:5, adjust edid.c to just use that format. If at some future time we need 4:4:4, which seems unlikely, we'll need to add a function to adjust the lb_framebuffer. Note that you can't just divine this from the EDID, as the graphics pipe format need not match the actual final format used. The EDID reading works. We've been requested to support hard-coded EDIDs and that will come in the next revision. Currently the hard-coded EDID is ignored for testing. Change-Id: Ib4d06dc3388ab90c834f94808a51133e5b515a4d Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/64240 Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Ronald G. Minnich <rminnich@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/4432 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-07-10PIT: memory setupRonald G. Minnich
Tested and working. Gets us to ramstage. Change-Id: Ib9ea4a6c912e8152246aaf4f1f084a4aa1626053 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3677 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5420: Make the ps_hold_setup function public.Gabe Black
This function had been declared in a public header file, but was marked static when actually defined. Change-Id: Ia551a5a12e7dbaf7bc00861e085695145ab7b91a Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3657 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10pit: Create an exynos5420 directory which is nearly a copy of exynos5250.Gabe Black
This change creates an exynos5420 directory with code that will eventually implement support for the exynos5420 cpu from Samsung. Currently it's a copy of the exynos5250 directory with the name changed. There are going to be some problems where headers in src/cpu/samsung/exynos-common include headers in the exynos5250 directory directly. Change-Id: Ia8d7244310d32499238bbc171c0c668ec48178e1 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3644 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>