In order to check this node by list_del_init().
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Change-Id: I723821d8b9fc6d899fbd5c0b830b240486a48c73
Previously we have to use serial node only from U-Boot dtb,
because we can't handle two problems to avoid serial intr fail:
- CRU phandle miss match between kernel and U-Boot dtb
- No "clock-frequency" in kernel serial node
These problems are workarund by current code, but the dm serial
seems to be works normally only for uart debug but not other uart.
Since the problems have been solved, let's allow serial driver-device
bind from kernel dtb.
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Change-Id: If3453509151e086afc5b7558277bec53842ac8eb
It works when CONFIG_USING_KERNEL_DTB is enabled, because we can
set either 'u-boot,dm-spl' or 'u-boot,dm-pre-reloc' for the node
that we can to leave in the u-boot.dtb.
Change-Id: Id3cec0c64ee55ca9bc1e5871e7ad5a2ebb4b1b6a
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Do not use mtd node from kernel dtb, otherwise the driver will
be initialized twice.
Change-Id: I6f3dca8fd8c3e05475f4359fe6c3c5312c0984cd
Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
There is not crypto node in kernel dtb for early platform(such as
rk322x/rk3288/rk3368/rk3399, etc), so we decide to add crypto node
always in U-Boot dtb and ignore crypto node from kernel dtb.
This is a way to compatible with early platforms. Actually, we
need crypto during secure boot sequence, the crypto had better
not depends on kernel dtb.
Change-Id: Ibab4fca0741b45042b8d0868240449fb6b52aa14
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Use "u-boot,dm-pre-reloc" to identify whether the existance
node is from U-Boot or not. This avoids deleting the same name
nodes from kernel dtb.
Change-Id: I6503965c0013053feefad7e93f98b01b5af71f44
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
We do not need to assign-clock for every driver in Rockchip platform,
only below module need this feature, remove it for boot time optimize:
- GMAC (need set parent from dts)
- CRU ARM clock (rockchip board will call set_armclk_rate() instead)
- VOP (need set parent)
Change-Id: Ie8facfb7499323f4649e0e1d908f850de1338e12
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Don't duplicate bind EMMC and NAND device after load kernel dtb.
Always use serial node from u-boot and use all other nodes from kernel.
Change-Id: Iaef9258f66f4f1060f057a9f7b194694e0e1df21
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Do not use nand node from kernel dtb, or the driver will
be initialized twice.
Change-Id: Iae3e76094d074549e6f52c20261ceefa9b98be1b
Signed-off-by: Yifeng Zhao <zyf@rock-chips.com>
With kernel dtb support, there are two dtbs and some devices may have
the same driver and nanme, the api uclass_get_device_by_driver() and
uclass_get_device_by_name() may get wrong value. In order to use cru
node in kernel dtb, remove the same device whose node is in u-boot dtb.
Change-Id: Id19eedb276731fa18b07bca51bbc203636f20c31
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Assigned clocks are widely used in kernel, but not in U-Boot yet,
many U-Boot clock driver do not have the API while dts port from kernel
have "assigned-clocks" node.
Just give a warning now instead of a device probe fail.
Change-Id: Icc1da8bdd1a21d6d118e37d305bd7909758c40b2
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
The driver for U-Boot and kernel are different, we can not re-use
mmc node from kernel now.
BTW: U-Boot need alias for mmc to make sure emmc at mmc0(not support
in kernel dtb).
Change-Id: I1b8fd3ab8a28e3abb5964dc113d0028abe2beaa2
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Linux uses the properties 'assigned-clocks', 'assigned-clock-parents'
and 'assigned-clock-rates' to configure the clock subsystem for use
with various peripheral nodes.
This implements clk_set_defaults() and hooks it up with the general
device probibin in drivers/core/device.c: when a new device is probed,
clk_set_defaults() will be called for it and will process the
properties mentioned above.
Note that this functionality is designed to fail gracefully (i.e. if a
clock-driver does not implement set_parent(), we simply accept this
and ignore the error) as not to break existing board-support.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Tested-by: David Wu <david.wu@rock-chips.com>
Series-changes: 2
- Fixed David's email address.
Series-version: 2
Cover-letter:
clk: support assigned-clock, assigned-clock-parents, assigned-clock-rates
For various peripherals on Rockchip SoCs (e.g. for the Ethernet GMAC),
the parent-clock needs to be set via the DTS. This adds the required
plumbing and implements the GMAC case for the RK3399.
END
(cherry picked from commit f4fcba5c5baaaa9d477d753f97124efdb8e45893)
Change-Id: I549891987c5a3e8546b96f1f54ad575950f92b12
Signed-off-by: David Wu <david.wu@rock-chips.com>
Judging from its name and parameters, device_is_compatible looks like it
is compatible with a live device tree, but it actually isn't.
Make it compatible with a live device tree.
Reviewed-by: Simon Glass <sjg@chromium.org>
Change-Id: I892142d611ab5068d4ec6bdb51666a673b679794
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit 29d11b8838bb2aa324b8873159cbd7088870a75b)
With kernel dtb support, there have two dtb and some device may the same,
skip it if already in the list, node in u-boot dtb will be used.
Change-Id: Ic9f8b73e3708a03416a9dc4ab6c72fa0184a6fdb
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
The size variable may not be always be a mulitple of
ARCH_DMA_MINALIGN and using it to flush cache leads to cache
misaligned warnings.
Therefore, round up the size to a multiple of ARCH_DMA_MINLAIGN
when allocating private data.
Change-Id: I29c4fb89f4be628518c2f5350d3efbccd28acd36
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit 5924da1dfe56d32a45b8adf29bdc8caf788bd4c8)
As we discussed before in ML, dm_dbg() causes undefined reference
error if #define DEBUG is added to users, but not drivers/core/util.c
We do not need this macro because we can use pr_debug() instead, and
it is pretty easy to enable it for the DM core by using ccflags-y.
Change-Id: I0732d1fec827d434b1163093920a3c5bd682803e
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
(cherry picked from commit ceb9190969e458dcd1427566f762dbb9cfdfdc94)
When a live tree is being used we need to record the node that was used to
create the device. Update device_bind_with_driver_data() to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
The of_ prefix conflicts with the livetree version of this function.
Rename it to avoid problems when we add livetree support.
Signed-off-by: Simon Glass <sjg@chromium.org>
This core function will need to work with a live tree also. Update it to
accept an ofnode instead of an offset.
Signed-off-by: Simon Glass <sjg@chromium.org>
With live tree we need a struct device_node * to reference a node. With
the existing flat tree, we need an int offset. We need to unify these into
a single value which can represent both.
Add an ofnode union for this and adjust existing code to move to this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this group of address-related functions into a new file. These use
the flat device tree. Future work will provide new versions of these which
can support the live tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is a strange interaction with drivers which use DMA if the cache
starts off in a dirty state. Buffer space which the driver reads (but has
not previously written) can contain zero bytes from alloc_priv(). This can
cause corruption of the memory used by DMA for incoming data.
Fix this and add a comment to explain the problem.
This allows the dwc2 driver to work correctly with driver model, for
example.
Signed-off-by: Simon Glass <sjg@chromium.org>
This patch adds the flags parameter to device_remove() and changes all
calls to this function to provide the default value of DM_REMOVE_NORMAL
for "normal" device removal.
This is in preparation for the driver specific pre-OS (e.g. DMA
cancelling) remove support.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
The currently available functions accessing the 'reg' property of a
device only retrieve the address. Sometimes its also necessary to
retrieve the size described by the 'reg' property. This patch adds
the new function dev_get_addr_size_index() which retrieves both,
the address and the size described by the 'reg' property.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Commit b02e4044ff ("libfdt: Bring in upstream stringlist
functions") broke codying style in some places especially
by inserting an extra whitespace before fdt_stringlist_count().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Simon Glass <sjg@chromium.org>
These have now landed upstream. The naming is different and in one case the
function signature has changed. Update the code to match.
This applies the following upstream commits by
Thierry Reding <treding@nvidia.com> :
604e61e fdt: Add functions to retrieve strings
8702bd1 fdt: Add a function to get the index of a string
2218387 fdt: Add a function to count strings
Signed-off-by: Simon Glass <sjg@chromium.org>
Some code may want to read reg values from DT, but from nodes that aren't
associated with DM devices, so using dev_get_addr_index() isn't
appropriate. In this case, fdtdec_get_addr_size_*() are the functions to
use. However, "translation" (via the chain of ranges properties in parent
nodes) may still be desirable. Add a function parameter to request that,
and implement it. Update all call sites to default to the original
behaviour.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Squashed in build fix from Stephen:
Signed-off-by: Simon Glass <sjg@chromium.org>
Devices which use of-platdata have their own platdata. However, in many
cases the driver will have its own auto-alloced platdata, for use with the
device tree. The ofdata_to_platdata() method converts the device tree
settings to platdata.
With of-platdata we would not normally allocate the platdata since it is
provided by the U_BOOT_DEVICE() declaration. However this is inconvenient
since the of-platdata struct is closely tied to the device tree properties.
It is unlikely to exactly match the platdata needed by the driver.
In fact a useful approach is to declare platdata in the driver like this:
struct r3288_mmc_platdata {
struct dtd_rockchip_rk3288_dw_mshc of_platdata;
/* the 'normal' fields go here */
};
In this case we have dt_platadata available, but the normal fields are not
present, since ofdata_to_platdata() is never called. In fact driver model
doesn't allocate any space for the 'normal' fields, since it sees that there
is already platform data attached to the device.
To make this easier, adjust driver model to allocate the full size of the
struct (i.e. platdata_auto_alloc_size from the driver) and copy in the
of-platdata. This means that when the driver's bind() method is called,
the of-platdata will be present, followed by zero bytes for the empty
'normal field' portion.
A new DM_FLAG_OF_PLATDATA flag is available that indicates that the platdata
came from of-platdata. When the allocation/copy happens, the
DM_FLAG_ALLOC_PDATA flag will be set as well. The dtoc tool is updated to
output the platdata_size field, since U-Boot has no other way of knowing
the size of the of-platdata struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
When CONFIG_SPL_OF_PLATDATA is enabled we should not access the device
tree. Remove all references to this in the core driver-model code.
Signed-off-by: Simon Glass <sjg@chromium.org>
This API helps to map physical register addresss pace of device to
virtual address space easily. Its just a wrapper around map_physmem()
with MAP_NOCACHE flag.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>
This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Provide an api to check whether the given device or machine is
compatible with the given compat string which helps in making
decisions in drivers based on device or machine compatible.
Idea taken from Linux.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
Some devices have a name that is stored in allocated memory. At present
there is no mechanism to free this memory when the device is unbound.
Add a device flag to track whether a name is allocated and a function to
add the flag. Free the memory when the device is unbound.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the device's own DT offset, not the device's parent's.
Fixes: 43c4d44e33 ("fdt: implement dev_get_addr_name()")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
On some platforms (e.g. x86), the return value of dev_get_addr() can't
be assigned to a pointer type variable directly. As there might be a
difference between the size of fdt_addr_t and the pointer type. On
x86 for example, "fdt_addr_t" is 64bit but "void *" only 32bit. So
assigning the register base directly in dev_get_addr() results in this
compilation warning:
warning: cast to pointer from integer of different size
This patch introduces the new function dev_get_addr_ptr() that
returns a pointer to the 'reg' address that can be used by drivers
in this case.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This function parses the reg property based on an index found in the
reg-names property. This is required for bindings that are written
using reg-names rather than hard-coding indices in reg.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Fix multi-line comment indentation in device_bind()
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We may have pinmux settings for pinctrl device, like the following
example:
"
&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hog_1>;
imx6ul-evk {
pinctrl_hog_1: hoggrp-1 {
fsl,pins = <
MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059 /* SD1 CD */
MX6UL_PAD_GPIO1_IO05__USDHC1_VSELECT 0x17059 /* SD1 VSELECT */
MX6UL_PAD_GPIO1_IO09__GPIO1_IO09 0x17059 /* SD1 RESET */
MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x80000000
>;
};
[......]
};
"
We should not only select pinctrl state for non pinctrl devices, we
need also to handle pin mux settings such as pinctrl_log for pinctrl
devices.
So at the end of probing process of pinctrl device, select the default
state of pinctrl device.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This function is not used as the use case for it did not eventuate. Remove
it to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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>
At present the uclass's post_bind() method is called before the driver's
bind() method. This means that the uclass cannot use any of the information
set up by the driver. Move it later in the sequence to permit this.
This is an ordering change which is always fairly major in nature. The main
impact is that devices which have children will not see them appear in their
bind() method. From what I can see, existing drivers do not look at their
children in the bind() method, so this should be safe.
Conceptually this change seems to result in a 'more correct' ordering, since
the uclass (which is broader than the device) gets the last word.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add new api to get device address based on index.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Jagan Teki <jteki@openedev.com>
[Rebased on master]
Signed-off-by: Jagan Teki <jteki@openedev.com>
Shawn Lin
Joseph Chen
Jason Zhu
Kever Yang
Yifeng Zhao
Finley Xiao
Philipp Tomsich
Mario Six
Faiz Abbas
Masahiro Yamada
Simon Glass
Stefan Roese
Stephen Warren
Vignesh R
Mugunthan V N
Peng Fan
Tom Rini