summaryrefslogtreecommitdiff
path: root/arch/x86/dts/chromebook_link.dts
Commit message (Collapse)AuthorAgeLines
* x86: dts: Drop memory SPD compatible stringSimon Glass2016-03-17-1/+0
| | | | | | | | This is not needed now that the memory controller driver has the SPD data in its own node. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: link: Add pin configuration to the device treeSimon Glass2016-03-17-0/+155
| | | | | | | | | | | | At present pin configuration on link does not use the standard mechanism, but some rather ugly custom code. As a first step to resolving this, add the pin configuration to the device tree. Four of the GPIOs must be available before relocation (for SDRAM pin strapping). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: dts: link: Add board ID GPIOsSimon Glass2016-03-17-0/+2
| | | | | | | | At present the board ID GPIOs are hard-coded. Move them to the device tree so that we can use general SDRAM init code. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: dts: link: Move SPD info into the memory controllerSimon Glass2016-03-17-111/+110
| | | | | | | | | | | The SDRAM SPD (Serial Presence Detect) information should be contained with the SDRAM controller. This makes it easier for the controller to access it and removes the need for a separate compatible string. As a first step, move the information. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: link: Add required GPIO propertiesSimon Glass2016-03-17-3/+9
| | | | | | | | In order to use GPIO phandles we need to add some GPIO properties as specified by the GPIO bindings. Add these for link. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ich6_gpio: Convert to use proper DM APIBin Meng2016-02-05-21/+21
| | | | | | | | | | | | | | | | At present this GPIO driver still uses the legacy PCI API. Now that we have proper PCH drivers we can use those to obtain the information we need. While the device tree has nodes for the GPIO peripheral it is not in the right place. It should be on the PCI bus as a sub-peripheral of the PCH device. Update the device tree files to show the GPIO controller within the PCH, so that PCI access works as expected. This also adds '#address-cells' and '#size-cells' to the PCH node. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* spi: ich: Use compatible strings to distinguish controller versionBin Meng2016-02-05-1/+1
| | | | | | | | | | At present ich spi driver gets the controller version information via pch, but this can be simply retrieved via spi node's compatible string. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jagan Teki <jteki@openedev.com> Tested-by: Simon Glass <sjg@chromium.org>
* x86: Correct spi node aliasBin Meng2016-01-28-2/+2
| | | | | | | | With recent changes spi node was moved to a place as a subnode under pch, so update the alias to refer to its correct place as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: Use syscon for the GMA deviceSimon Glass2016-01-24-1/+2
| | | | | | | | | Until we have a proper video uclass we can use syscon to handle the GMA device, and avoid the special device tree and PCI searching. Update the code to work this way. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Drop special EHCI initSimon Glass2016-01-24-0/+12
| | | | | | | | | | This is not needed. On reset wake-on-disconnect is already set. It may a problem during a soft reset or resume, but for now it does not seem important. Also drop the command register update since PCI auto-config does it for us. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert SDRAM init to use driver modelSimon Glass2016-01-24-0/+6
| | | | | | | | | SDRAM init needs access to the Northbridge controller and the Intel Management Engine device. Add the latter to the device tree and convert all of this code to driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Use the I2C driver to perform SMbus initSimon Glass2016-01-24-0/+6
| | | | | | | | Move the init code into the I2C driver. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Drop the special PCI driverSimon Glass2016-01-24-1/+1
| | | | | | | | There is nothing special about the ivybridge pci driver now, so just use the generic one. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Do the SATA init before relocationSimon Glass2016-01-24-7/+9
| | | | | | | | | The SATA device needs to set itself up so that it appears correctly on the PCI bus. The easiest way to do this is to set it up to probe before relocation. This can do the early setup. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Use common CPU init codeSimon Glass2016-01-24-0/+34
| | | | | | | | | The existing ivybridge code predates the normal multi-core CPU init, and it is not used. Remove it and add CPU nodes to the device tree so that all four CPUs are set up. Also enable the 'cpu' command. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Add a driver for the bd82x6x northbridgeSimon Glass2016-01-24-0/+7
| | | | | | | | Add a driver with an empty probe function where we can move init code in follow-on patches. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Move lpc_early_init() to probe()Simon Glass2016-01-24-2/+1
| | | | | | | | Move this code to the LPC's probe() method so that it will happen automatically when the LPC is probed before relocation. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Set up the LPC device using driver modelSimon Glass2016-01-24-0/+1
| | | | | | | | | | Find the LPC device in arch_cpu_init_dm() as a first step to converting this code to use driver model. Probing the LPC will probe its parent (the PCH) automatically, so make sure that probing the PCH does nothing before relocation. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* dm: x86: spi: Convert ICH SPI driver to driver model PCI APISimon Glass2016-01-24-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | At present this SPI driver works by searching the PCI buses for its peripheral. It also uses the legacy PCI API. In addition the driver has code to determine the type of Intel PCH that is used (version 7 or version 9). Now that we have proper PCH drivers we can use those to obtain the information we need. While the device tree has a node for the SPI peripheral it is not in the right place. It should be on the PCI bus as a sub-peripheral of the LPC device. Update the device tree files to show the SPI controller within the PCH, so that PCI access works as expected. This patch includes Bin's fix-up patch from here: https://patchwork.ozlabs.org/patch/569478/ Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Convert to use driver model timerBin Meng2015-12-01-0/+1
| | | | | | | Convert all x86 boards to use driver model tsc timer. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add an i8042 device for boards that have itSimon Glass2015-11-19-0/+5
| | | | | | | | | | | | Some boards have an i8042 device. Enable the driver for all x86 boards, and add a device tree node for those which may have this keyboard. Also adjust the configuration so that i8042 is always separate from the VGA, and rename the stdin driver accordingly. With this commit the keyboard will not work, but it is fixed in the next commit. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: Remove unused rw-mrc-cache properties in the link and panther dts filesBin Meng2015-10-21-2/+0
| | | | | | | | | "type" and "wipe-value" are never used by the mrccache codes. Remove them to avoid confusion. This also removes the alignment comment in the panther dts file. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* exynos: x86: dts: Add tpm nodes to the device tree for Chrome OS devicesSimon Glass2015-08-31-0/+5
| | | | | | | | | Add a TPM node to the various Chromebooks so that driver can be converted to driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Christophe Ricard<christophe-h.ricard@st.com> Reviewed-by: Heiko Schocher <hs@denx.de>
* x86: Enable DM RTC support for all x86 boardsBin Meng2015-07-28-0/+1
| | | | | | | | Add a RTC node in the device tree to enable DM RTC support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> (Squashed in 'x86: Fix RTC build error on ivybridge')
* x86: link: Add PCH driver to support SPI FlashSimon Glass2015-04-29-1/+1
| | | | | | | | U-Boot on coreboot does not have a driver for the PCH so cannot see the SPI peripheral now that it has moved inside the PCH. Add a simple driver so that SPI flash works again. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: chromebook_link: dts: Add PCH and LPC devicesSimon Glass2015-04-18-31/+39
| | | | | | | | | | | | The PCH (Platform Controller Hub) is on the PCI bus, so show it as such. The LPC (Low Pin Count) and SPI bus are inside the PCH, so put these in the right place also. Rename the compatible strings to be more descriptive since this board is the only user. Once we are using driver model fully on x86, these will be dropped. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: x86: pci: Convert chromebook_link to use driver model for pciSimon Glass2015-04-18-1/+2
| | | | | | | | | | | | | | | | Move chromebook_link over to driver model for PCI. This involves: - adding a uclass for platform controller hub - removing most of the existing PCI driver - adjusting how CPU init works to use driver model instead - rename the lpc compatible string (it will be removed later) This does not really take advantage of driver model fully, but it does work. Furture work will improve the code structure to remove many of the explicit calls to init the board. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: x86: pci: Convert coreboot to use driver model for pciSimon Glass2015-04-18-0/+7
| | | | | | Move coreboot-x86 over to driver model for PCI. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: dts: Add SPI flash MRC details for chromebook_linkSimon Glass2015-01-24-1/+14
| | | | | | | | Correct the SPI flash compatible string, add an alias and specify the position of the MRC cache, used to store SDRAM training settings for the Memory Reference Code. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Make chromebook_link the default board for corebootBin Meng2015-01-13-1/+216
| | | | | | | | | | | | | | | Change SYS_CONFIG_NAME and DEFAULT_DEVICE_TREE to chromebook_link which is currently the only real board officially supported to run U-Boot loaded by coreboot. Note the symbolic link file chromebook_link.dts is deleted and link.dts is renamed to chromebook_link.dts. To avoid multiple definition of video_hw_init, the CONFIG_VIDEO_X86 define needs to be moved to arch/x86/cpu/ivybridge/Kconfig. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: Add chromebook_link boardSimon Glass2014-11-21-0/+1
This board is a 'bare' version of the existing 'link 'board. It does not require coreboot to run, but is intended to start directly from the reset vector. This initial commit has place holders for a wide range of features. These will be added in follow-on patches and series. So far it cannot be booted as there is no ROM image produced, but it does build without errors. Signed-off-by: Simon Glass <sjg@chromium.org>