summaryrefslogtreecommitdiff
path: root/arch/x86
Commit message (Collapse)AuthorAgeLines
* dm: Use uclass_first_device_err() where it is usefulSimon Glass2016-03-14-20/+12
| | | | | | Use this new function in places where it simplifies the code. Signed-off-by: Simon Glass <sjg@chromium.org>
* x86: Add Intel Cougar Canyon 2 boardBin Meng2016-02-21-0/+109
| | | | | | | | | This adds basic support to Intel Cougar Canyon 2 board, a board based on Chief River platform with an Ivy Bridge processor and a Panther Point chipset. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: bd82x6x: Support FSP enabled configurationBin Meng2016-02-21-1/+5
| | | | | | | | Wrap initialization codes with #ifndef CONFIG_HAVE_FSP #endif, and enable the build for both FSP and non-FSP configurations. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* x86: fsp: Make sure HOB list is not overwritten by U-BootBin Meng2016-02-21-0/+43
| | | | | | | | | | | | | | | | | | | | | Intel IvyBridge FSP seems to be buggy that it does not report memory used by FSP itself as reserved in the resource descriptor HOB. The FSP specification does not describe how resource descriptor HOBs are generated by the FSP to describe what memory regions. It looks newer FSPs like Queensbay and BayTrail do not have such issue. This causes U-Boot relocation overwrites the important boot service data which is used by FSP, and the subsequent call to fsp_notify() will fail. To resolve this, we find out the lowest memory base address allocated by FSP for the boot service data when walking through the HOB list in fsp_get_usable_lowmem_top(). Check whether the memory top address is below the FSP HOB list, and if not, use the lowest memory base address allocated by FSP as the memory top address. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on link (ivybridge non-FSP) Tested-by: Simon Glass <sjg@chromium.org>
* x86: ivybridge: Add FSP supportBin Meng2016-02-21-0/+131
| | | | | | | | | | IvyBridge FSP package is built with a base address at 0xfff80000, and does not use UPD data region. This adds basic FSP support. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Tested on link (ivybridge non-FSP) Tested-by: Simon Glass <sjg@chromium.org>
* x86: fix memalign() parameter orderStephen Warren2016-02-21-1/+1
| | | | | | | | | | | | Purely by code inspection, it looks like the parameter order to memalign() is swapped; its parameters are (align, size). 4096 is a likely desired alignment, and a variable named size sounds like a size:-) Fixes: 45b5a37836d5 ("x86: Add multi-processor init") Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* Merge branch 'agust@denx.de' of git://git.denx.de/u-boot-stagingTom Rini2016-02-08-2/+2
|\
| * Use correct spelling of "U-Boot"Bin Meng2016-02-06-2/+2
| | | | | | | | | | | | | | | | | | | | Correct spelling of "U-Boot" shall be used in all written text (documentation, comments in source files etc.). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
* | x86: Drop pci_type1.c and DEFINE_PCI_DEVICE_TABLEBin Meng2016-02-05-60/+0
| | | | | | | | | | | | | | | | | | Now that we have converted all x86 codes to DM PCI, drop pci_type1.c which is only built for legacy PCI. Also per checkpatch.pl warning, DEFINE_PCI_DEVICE_TABLE is now deprecated so drop that too. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | x86: Disable DM_PCI_COMPATBin Meng2016-02-05-3/+0
| | | | | | | | | | | | | | Now that all x86 codes have been converted to use proper DM PCI APIs, it's time to disable the legacy compatible layer. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
* | x86: quark: Use Quark's own PCI config APIsBin Meng2016-02-05-2/+3
| | | | | | | | | | | | | | | | | | There are still two places in Quark's MRC codes that use the generic legacy PCI APIs, but as we are phasing out these legacy APIs, switch to use Quark's own PCI config routines. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | x86: pci: Drop legacy PCI APIsBin Meng2016-02-05-65/+0
| | | | | | | | | | | | | | | | | | Now that we have converted all x86 codes to use DM PCI APIs, drop those legacy ones. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: pci: Use DM PCI APIs in pci_assign_irqs()Bin Meng2016-02-05-3/+3
| | | | | | | | | | | | | | | | Drop legacy PCI APIs usage in pci_assign_irqs() as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: qemu: Convert to use DM PCI APIBin Meng2016-02-05-17/+17
| | | | | | | | | | | | | | | | Use pci_[read|write]_config intead of x86_pci_[read|write]_config. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: tnc: Remove IGD and SDVO devices from driver modelBin Meng2016-02-05-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With recent DM PCI changes to vesa_fb driver, external graphics card does not work any more. This is because: after setting the function disable bit, IGD and SDVO devices will disappear in the PCI configuration space. This however creates an inconsistent state from a driver model PCI controller point of view, as these two PCI devices are still attached to its parent's child device list as maintained by the driver model. Some driver model PCI APIs like dm_pci_find_class() used in the vesa_fb driver, are referring to the list to speed up the finding process instead of re-enumerating the whole PCI bus, so it gets the stale cached data which is wrong. To fix this, manually remove these two devices. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: tnc: Use DM PCI API in disable_igd()Bin Meng2016-02-05-3/+19
| | | | | | | | | | | | | | | | | | Once we get udevice of IGD and SDVO, we can use its udevice to access PCI configuration space with dm_pci_write_config32(). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: tnc: Change disable_igd() to have a return valueBin Meng2016-02-05-3/+7
| | | | | | | | | | | | | | | | | | So far disable_igd() does not have any return value, but we may need that in the future. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: irq: Convert to use DM PCI APIBin Meng2016-02-05-4/+4
| | | | | | | | | | | | | | | | | | Now that we have irq router's udevice passed as a parameter, it's time to start using the DM PCI API instead of those legacy ones. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: irq: Move irq_router to a per driver privBin Meng2016-02-05-46/+51
| | | | | | | | | | | | | | | | | | | | | | At present irq_router is declared as a static struct irq_router in arch/x86/cpu/irq.c. Since it's a driver control block, it makes sense to move it to a per driver priv. Adjust existing APIs to accept an additional parameter of irq_router's udevice. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: irq: Get irq_router's bdf via dm_pci_get_bdf()Bin Meng2016-02-05-8/+1
| | | | | | | | | | | | | | | | | | There is no need to parse PCH's <reg> property as we have already a DM PCI API dm_pci_get_bdf() that can handle this. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: minnowmax: Drop io-base property in the pch_pinctrl nodeBin Meng2016-02-05-1/+0
| | | | | | | | | | | | | | | | IOBASE is now obtained from PCH driver, drop this <io-base> property. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: Drop asm/arch/gpio.hBin Meng2016-02-05-89/+0
| | | | | | | | | | | | | | | | | | asm/arch/gpio.h is not needed anymore as we get the GPIO base from PCH driver. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: ich6_gpio: Convert to use proper DM APIBin Meng2016-02-05-153/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | x86: pch: Implement get_gpio_base opBin Meng2016-02-05-0/+33
| | | | | | | | | | | | | | | | Implement get_gpio_base op for bd82x6x, pch7 and pch9 drivers. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | dm: pch: Rename get_sbase op to get_spi_baseBin Meng2016-02-05-2/+2
| | | | | | | | | | | | | | | | Spell out 'sbase' to 'spi_base' so that it looks clearer. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | dm: pch: Remove pch_get_version opBin Meng2016-02-05-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | pch_get_version op was only used by the ich spi controller driver, and does not really provide a good identification of pch controller so far, since we see plenty of Intel PCH chipsets and one differs from another a lot, which is not simply either a PCHV_7 or PCHV_9. Now that ich spi controller driver was updated to not get such info from pch, the pch_get_version op is useless now. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: quark: Drop unprotect_spi_flash()Bin Meng2016-02-05-17/+0
| | | | | | | | | | | | | | | | | | Unprotecting SPI flash is now handled in the SPI controller driver, via a call to the PCH driver. Drop the ad-hoc version. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* | x86: tnc: Drop unprotect_spi_flash()Bin Meng2016-02-05-16/+0
| | | | | | | | | | | | | | | | | | Unprotecting SPI flash is now handled in the SPI controller driver, via a call to the PCH driver. Drop the ad-hoc version. 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-7/+7
|/ | | | | | | | | | 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-14/+14
| | | | | | | | 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: config option for loading ACPI table from QEMUMiao Yan2016-01-28-0/+9
| | | | | | | | | This patch adds a config option for loading ACPI table from QEMU. When enabled, U-Boot won't generate ACPI tables, but use those provided by QEMU. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: add the ability to load and link ACPI tables from QEMUMiao Yan2016-01-28-0/+322
| | | | | | | | | | | This patch adds the ability to load and link ACPI tables provided by QEMU. QEMU tells guests how to load and patch ACPI tables through its fw_cfg interface, by adding a firmware file 'etc/table-loader'. Guests are supposed to parse this file and execute corresponding QEMU commands. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: setup PM IO base for ACPI in southbridgeMiao Yan2016-01-28-0/+43
| | | | | | | | Enable ACPI IO space for piix4 (for pc board) and ich9 (for q35 board) Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: qemu: re-structure qemu_fwcfg_list_firmware()Miao Yan2016-01-28-17/+55
| | | | | | | | | Re-write the logic in qemu_fwcfg_list_firmware(), add a function qemu_fwcfg_read_firmware_list() to handle reading firmware list. Signed-off-by: Miao Yan <yanmiaobest@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
* x86: baytrail: Add option to disable the internal UART to setup_early_uart()Stefan Roese2016-01-28-5/+9
| | | | | | | | | | | This patch adds a parameter to the function setup_early_uart() to either enable or disable the internal BayTrail legacy UART. Since the name setup_early_uart() does not match its functionality any more, lets rename it to setup_internal_uart() as well in this patch. Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-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-15/+17
| | | | | | | | | 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: Set up a shared syscon numbering schemaSimon Glass2016-01-24-4/+14
| | | | | | | | | Each system controller can have a number to identify it. It can then be accessed using syscon_get_by_driver_data(). Put this in a shared header file and update the only current user. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Drop the SMM-locking codeSimon Glass2016-01-24-57/+0
| | | | | | | | U-Boot does not support SMM yet, so we can drop this code. It is easy to bring back when needed. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Drop XHCI supportSimon Glass2016-01-24-34/+0
| | | | | | | This is not used on link which is the only ivybridge board. Drop this code. 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-34/+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: Sort out the calls to bridge_silicon_revision()Simon Glass2016-01-24-42/+46
| | | | | | | | This function is called all over the place. Convert it use the driver model PCI API, and rationalise the calls. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Move code from pch.c to bd82x6x.cSimon Glass2016-01-24-145/+129
| | | | | | | This code relates to the PCH, so we should move it into the same file. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert pch.c to use DM PCI APISimon Glass2016-01-24-32/+76
| | | | | | | Convert this file to use the driver model PCI API. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert report_platform to DM PCI APISimon Glass2016-01-24-7/+8
| | | | | | | Convert these functions to use the driver model PCI API. 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-38/+101
| | | | | | | | | 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: Convert sdram_initialise() to use DM PCI APISimon Glass2016-01-24-9/+10
| | | | | | | | Convert this function to use the the driver model PCI API. We just need to pass in the northbridge device. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert dram_init() to use DM PCI APISimon Glass2016-01-24-14/+25
| | | | | | | | Convert the top part of the DRAM init to use the driver model PCI API. Further work will complete the transformation. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* x86: ivybridge: Convert enable_usb_bar() to use DM PCI APISimon Glass2016-01-24-17/+17
| | | | | | | | | Convert this function over to use the driver model PCI API. In this case we want to avoid using the real PCI devices since they have not yet been probed. Instead, write directly to their PCI configuration address. 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-36/+9
| | | | | | | | 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: Convert lpc init code to DM PCI APISimon Glass2016-01-24-63/+66
| | | | | | | | Adjust this code to use the driver model PCI API. This is all called through lpc_init_extra(). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>