Simon Glass [Sun, 17 Jan 2016 23:11:46 +0000 (16:11 -0700)]
x86: ivybridge: Convert enable_usb_bar() to use DM PCI API
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>
Simon Glass [Sun, 17 Jan 2016 23:11:44 +0000 (16:11 -0700)]
x86: i2c: Add a stub driver for Intel I2C/SMbus
This is used on most Intel platforms. We don't have a driver for it yet, but
add a stub to handle the init. For now this targets ivybridge so we may want
to add a device tree binding and generalise it when other platforms are
supported.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 17 Jan 2016 23:11:35 +0000 (16:11 -0700)]
x86: ivybridge: Do the SATA init before relocation
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>
Simon Glass [Sun, 17 Jan 2016 23:11:34 +0000 (16:11 -0700)]
ahci: Add a disk-controller uclass
Add a uclass ID for a disk controller. This can be used by AHCI/SATA or
other controller types. There are no operations and no interface so far,
but it is possible to probe a SATA device.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 17 Jan 2016 23:11:32 +0000 (16:11 -0700)]
x86: ivybridge: Use driver model PCI API in bd82x6x.c
Adjust most of the remaining functions in this file to use the driver model
PCI API. The one remaining function is bridge_silicon_revision() which will
need a little more work.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 17 Jan 2016 23:11:31 +0000 (16:11 -0700)]
x86: ivybridge: Move northbridge and PCH init into drivers
Instead of calling the northbridge and PCH init from bd82x6x_init_extra()
when the PCI bus is probed, call it from the respective drivers. Also drop
the Northbridge init as it has no effect. The registers it touches appear to
be read-only.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 17 Jan 2016 23:11:30 +0000 (16:11 -0700)]
x86: Bring up northbridge, pch and lpc after the CPUs
These devices currently need to be inited early in boot. Once we have the
init in the right places (with each device doing its own init and no
problems with ordering) we should be able to remove this. For now it is
needed to keep things working.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 17 Jan 2016 23:11:25 +0000 (16:11 -0700)]
x86: ivybridge: Set up the thermal target correctly
This uses a non-existent node at present. It should use the first CPU node.
The referenced property does not exist (the correct value is the default of
0), but this allows the follow-on init to complete.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Sun, 17 Jan 2016 23:11:23 +0000 (16:11 -0700)]
x86: ivybridge: Use common CPU init code
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>
Simon Glass [Sun, 17 Jan 2016 23:11:10 +0000 (16:11 -0700)]
x86: ivybridge: Set up the LPC device using driver model
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>
Simon Glass [Wed, 20 Jan 2016 04:32:27 +0000 (21:32 -0700)]
dm: x86: Add a common PIRQ init function
Most x86 interrupt drivers will want to use the standard PIRQ routing and
table setup. Put this code in a common function so it can be used by those
drivers that want it.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 20 Jan 2016 04:32:26 +0000 (21:32 -0700)]
dm: x86: Set up interrupt routing from interrupt_init()
At present interrupt routing is set up from arch_misc_init(). We can do it
a little later instead, in interrupt_init().
This removes the manual pirq_init() call. Where the platform does not have
an interrupt router defined in its device tree, no error is generated. Some
platforms do not have this.
Drop pirq_init() since it is no-longer used.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Wed, 20 Jan 2016 04:32:25 +0000 (21:32 -0700)]
dm: x86: Create a driver for x86 interrupts
It seems likely that at some point we will want a generic interrupt uclass.
But this is a big undertaking as it involves unifying code across multiple
architectures.
As a first step, create a simple IRQ uclass and a driver for x86. This can
be generalised later as required.
Adjust pirq_init() to probe this driver, which has the effect of creating
routing tables and setting up the interrupt routing. This is a start
towards making interrupts fit better with driver model.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 19 Jan 2016 03:19:21 +0000 (20:19 -0700)]
dm: x86: spi: Convert ICH SPI driver to driver model PCI API
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>
Simon Glass [Tue, 19 Jan 2016 03:19:20 +0000 (20:19 -0700)]
spi: ich: Separate out the read/write trace from normal debugging
The trace is seldom useful for basic debugging. Allow it to be enabled
separately so that it is easier to see the more important init and error
debug messages.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 19 Jan 2016 03:19:19 +0000 (20:19 -0700)]
dm: x86: Add a driver for Intel PCH9
At some point we may need to distinguish between different types of PCHs,
but for existing supported platforms we only need to worry about version 7
and version 9 bridges. Add a driver for the PCH9.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 19 Jan 2016 03:19:18 +0000 (20:19 -0700)]
dm: x86: Add a driver for Intel PCH7
At some point we may need to distinguish between different types of PCHs,
but for existing supported platforms we only need to worry about version 7
and version 9 bridges. Add a driver for the PCH7.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Tue, 19 Jan 2016 03:19:17 +0000 (20:19 -0700)]
dm: Expand the uclass for Platform Controller Hubs (PCH)
A Platform Controller Hub is an Intel concept - it is like the peripherals
on an SoC and is often in a separate chip from the CPU. The chip is typically
found on the first PCI bus and integrates multiple devices.
We have a very simple uclass to support PCHs. Add a few operations, such as
setting up the devices on the PCH and finding the SPI controller base
address. Also move it into drivers/pch/ since we will be adding a few PCH
drivers.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 22 Jan 2016 02:45:25 +0000 (19:45 -0700)]
rockchip: Update the README
GPIO, I2C, LCD and HDMI are now implemented. We have more than one PMIC.
There is an implementation to run the CPU at full speed although it does
not seem to make much difference.
Simon Glass [Fri, 22 Jan 2016 02:45:19 +0000 (19:45 -0700)]
rockchip: jerry: Enable EDP and HDMI video output
Enable these devices using the VOPL video output device. We explicitly
disable VOPB in the device tree to avoid it taking over. Since this device
has an LCD display this comes up by default. If the display fails for some
reason then it will attempt to use HDMI. It is possible to force it to fail
(and thus fall back to HDMI) by puting 'return -EPERM' at the top of
rk_edp_probe(). For now there is no easy way to select between the two.
Simon Glass [Fri, 22 Jan 2016 02:45:08 +0000 (19:45 -0700)]
rockchip: Add a script to parse datasheets
This script has proved useful for parsing datasheets and creating register
shift/mask values for use in header files. Include it in case it is useful
for others.
Simon Glass [Fri, 22 Jan 2016 02:45:05 +0000 (19:45 -0700)]
rockchip: video: Add a video-output driver
Some rockchip SoCs include video output (VOP). Add a driver to support this.
It can output via a display driver (UCLASS_DISPLAY) and currently HDMI and
eDP are supported.
Simon Glass [Fri, 22 Jan 2016 02:45:03 +0000 (19:45 -0700)]
rockchip: video: Add a display driver for rockchip HDMI
Some Rockchip SoCs support HDMI output. Add a display driver for this so
that these displays can be used on supported boards.
Unfortunately this driver is not fully functional. It cannot reliably read
EDID information over HDMI. This seems to be due to the clocks being
incorrect - the I2C bus speed appears to be up to 100x slower than the
clock settings indicate. The root cause may be in the clock logic.
Simon Glass [Fri, 22 Jan 2016 02:45:00 +0000 (19:45 -0700)]
dm: video: Repurpose the 'displayport' uclass to 'display'
The current DisplayPort uclass is too specific. The operations it provides
are shared with other types of output devices, such as HDMI and LVDS LCD
displays.
Generalise the uclass so that it can be used with these devices as well.
Adjust the uclass to handle the EDID reading and conversion to
display_timing internally.
Simon Glass [Fri, 22 Jan 2016 02:44:59 +0000 (19:44 -0700)]
video: panel: Add a simple panel driver
Most panels are very simple - they just have a power supply and a backlight.
Add a driver which supports this and implements the enable_backlight()
method.
Simon Glass [Fri, 22 Jan 2016 02:44:58 +0000 (19:44 -0700)]
dm: panel: Add a panel uclass
LCD panels can usefully be modelled as their own uclass. They can be probed
(which powers them up ready for use). If they have a backlight, this can be
enabled.
Simon Glass [Fri, 22 Jan 2016 02:44:56 +0000 (19:44 -0700)]
dm: backlight: Add a backlight uclass
LCD panels normally have a backlight which can be controlled to illuminate
the LCD contents. Add a uclass to support this. Initially it only has a
method to enable the backlight.
Simon Glass [Fri, 22 Jan 2016 02:44:51 +0000 (19:44 -0700)]
video: Name consoles by their number
We must use the console name in the 'stdout' variable to select the one
we want. At present the name is formed from the driver name with a suffix
indicating the rotation value.
It seems better to name them sequentially since this can be controlled by
driver order. So adjust the code to use 'vidconsole' for the first,
'vidconsole1' for the second, etc.
Simon Glass [Fri, 22 Jan 2016 02:44:50 +0000 (19:44 -0700)]
gpio: Warn about invalid GPIOs used with the 'gpio' command
At present there is no indication that an invalid GPIO is used except that
the GPIO status is not displayed. Make the error more explicit to avoid
confusion.