| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
|
|
|
| |
The correct pinctrl is handled automatically so we don't need to do it in
the driver. The exception is when we want to use a different chip select
(other than 0). But this isn't used at present.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
At present there is an incorrect call to rkspi_enable_chip(). It should
be disabling the chip, not enabling it. Correct this and ensure that the
chip is disabled when releasing the bus.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
Some devices need delays before and after activiation. Implement these
features in the SPI driver so that we will be able to enable the Chrome
OS EC.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
Provide this method so that 'gpio status' works fully. It now shows
whether a pin is used for input, output or some other function.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
| |
This function should return 0 or 1, not a mask. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
Implement this so that the GPIO command will be able to report whether a
GPIO is used for input or output.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
This file has many features that are not needed by SPL. Use #ifdef to
remove the unused features and reduce the code size.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current method assumes that clocks are numbered from 0 and we can
determine a clock by its number. It is safer to use an ID in the clock's
platform data to avoid the situation where another clock is bound before
the one we expect.
Move the existing code into rk3036 since it still works there. Add a new
implementation for rk3288.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
Two of the init values are created locally so cannot be out of range.
The masking is unnecessary and in one case is incorrect. Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
Rather than changing the clock to the same value on every transaction,
remember the last value and don't adjust the clock unless it is necessary.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
This function adds quite a bit of code to SPL and we probably don't need
all the features in SPL. Add a simple version (for SPL only) to save space.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
Some regulators will not implement any operations (e.g. fixed regulators).
This is not an error, so allow the autoset process to continue when one
of these regulators is found.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
The currect PMIC debugging is a little confusing. Adjust it so that it is
clear whether the operation succeeded or failed. Also, avoid creating a new
error return value when a perfectly good one is already available.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
It is sometimes useful to be able to find a device before probing it,
perhaps to set up some platform data for it. Allow finding by of_offset
also.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GPIO drivers want to be able to show if a pin is enabled for input, output,
or is being used by another function. Some drivers can easily find this
and the code is included in the driver. For some SoCs this is more complex.
Conceptually this should be handled by pinctrl rather than GPIO. Most
pinctrl drivers will have this feature anyway.
Add a method by which a GPIO driver can obtain the pin mux value given a
GPIO reference. This avoids repeating the code in two places.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
For some boards the pmic interface is useful but the regulator interface
(which comes with it) is too large. Allow them to be separated such that
SPL can decide which it needs.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This function currently searches the entire device tree for a node that
it thinks is relevant. But the node is known and is passed in. Correct the
code and enable it only with driver model, since only driver-model boards
will use it.
This avoids bringing in a large number of strings from fdtdec.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
Since I2C muxes are seldom needed in SPL, and the code for this increases
the size somewhat, add a separate option to enable I2C muxes for SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
This is not used in SPL so don't allow it to be built there, even if I2C
is enabled in SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
We can make use of the device tree to configure pinctrl settings. Add this
support for the driver so we can use it in U-Boot proper.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
| |
We can use the new clk_get_by_index() function to get the correct clock.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
If full pinctrl is enabled we don't need to manually set the pinctrl in the
driver. It will happen automatically. Adjust the code to suit - we will
still use manual mode in SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
| |
We can use the new clk_get_by_index() function to get the correct clock.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
| |
We can use the new clk_get_by_index() function to get the correct clock.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
The current approach of using uclass_get_device() is error-prone. Another
clock (for example a fixed-clock) may cause it to break. Add a function that
does a proper search.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
It is useful to be able to read the rate of a peripheral clock. Add a
handler for that.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
| |
The current name is confusing and a bit verbose. Rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
| |
At present we use the same peripheral ID for clocks and pinctrl. While this
works it is probably better to use the device tree clock binding ID for
clocks. We can use the clk_get_by_index() function to find this.
Update the clock drivers and the code that uses them.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
Use the pwrseq uclass to find a suitable power sequence for the MMC device.
If this is enabled in the device tree, we will pick it up automatically.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
| |
This is easier to deal with when using generic code since it allows us to
use a register index instead of naming each register.
Adjust it, adding an enum to improve readability.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
Some devices need special sequences to be used when starting up. Add a
uclass for this. Drivers can be added to provide specific features as
needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
| |
Add regulator support for the RK808 PMIC. It integrated 4 BUCKs and 8 LDOs
all of which are supported by this driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
| |
This Rockchip PMIC provides features suitable for battery-powered
applications. It is commonly used with Rockchip SoCs.
Add a driver which provides register access. The regulator driver will use
this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
Add a function which produces a flags word from a few common PIN_CONFIG
settings. This is useful for simple pinctrl drivers that don't need to worry
about drive strength, etc.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is sort-of race condition when a pinctrl device is probed. The pinctrl
function is called which may end up using the same device as is being
probed. This results in operations being used before the device is actually
probed.
For now, disallow pinctrl operations on pinctrl devices while probing. An
alternative solution would be to move the operation to later in the
device_probe() function (for pinctrl devices only) but this needs more
thought.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
|
|
| |
Call dm_scan_fdt_node() in rk3036 pinctrl uclass binding.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
|
|
|
|
|
|
|
| |
Add a method which can locate a clock for a device, given its index. This
uses the normal device tree bindings to return the clock device and the
first argument which is normally used as a peripheral ID in U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit intends to implement "fixed-clock" as in Linux.
(drivers/clk/clk-fixed-rate.c in Linux)
If you need a very simple clock to just provide fixed clock rate
like a crystal oscillator, you do not have to write a new driver.
This driver can support it.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add tests that check that the video console is working correcty. Also check
that text output produces the expected result. Test coverage includes
character output, wrapping and scrolling.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Now that driver model support is available, convert sandbox over to use it.
We can remove a few of the special hooks that sandbox currently has.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Move this option to Kconfig. This is quite simple as only sandbox uses the
driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This command can use the bitmap display code in the uclass. This is similar
to the code in lcd.c and cfb_console.c. These other copies will go away when
all boards are converted to use driver model for video.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Sometimes the console must be rotated. Add a driver which supports rotating
the text clockwise to 90, 180 and 270 degrees. This can support devices
where the display is rotated for mechanical reasons.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Most of the time we don't need to rotate the display so a simple font
blitting feature is enough for our purposes. Add a simple driver which
supports this function. It provides text output on the console using
the standard 8x16-pixel font.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The existing LCD/video interface suffers from conflating the bitmap display
with text output on that display. As a result the implementation is more
complex than it needs to me.
We can support multiple text console drivers. Create a separate uclass to
support this, with its own API.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
U-Boot has separate code for LCDs and 'video' devices. Both now use a
very similar API thanks to earlier work by Nikita Kiryanov. With the driver-
model conversion we should unify these into a single uclass.
Unfortunately there are different features supported by each. This
implementation provides for a common set of features which should serve
most purposes. The intent is to support:
- bitmap devices with 8, 16 and 32 bits per pixel
- text console wih white on black or vice versa
- rotated text console
- bitmap display (BMP format)
More can be added as additional boards are ported over to use driver model
for video.
The name 'video' is chosen for the uclass since it is more generic than LCD.
Another option would be 'display' but that would introduce a third concept
to U-Boot which seems like the wrong approach.
The existing LCD and video init functions are not needed now, so this uclass
makes no attempt to implement them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This adds driver model support to lpuart serial driver.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Tested-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Create internal routines which take lpuart's register base as
a parameter, in preparation for driver model conversion.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is no need to go through serial driver subsystem, instead
call the driver's setbrg and putc routines directly.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
|