In case where a single timing resolution is implemented in the
device-tree, the property is named "panel-timing", as specify
in Linux kernel binding file:

Documentation/devicetree/bindings/display/panel/panel-common.yaml

  # Display Timings
  panel-timing:
    description:
      Most display panels are restricted to a single resolution and
      require specific display timings. The panel-timing subnode expresses those
      timings.
    $ref: panel-timing.yaml#

  display-timings:
    description:
      Some display panels support several resolutions with different timings.
      The display-timings bindings supports specifying several timings and
      optionally specifying which is the native mode.
    $ref: display-timings.yaml#

Fixes: 0347cc773270 ("drivers: core: ofnode: Add panel timing decode.")
Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

Update various build and test components to use the new schema.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add a CONFIG option to deal with this automatically, printing a warning
when U-Boot starts up. This can be useful if the device tree comes from
another project.

We will maintain this through the 2023.07 release, providing 6 months
for people to notice.

Signed-off-by: Simon Glass <sjg@chromium.org>
Version 4:
Acked-by: Michal Simek <michal.simek@amd.com>

ofnode_decode_display_timing supports reading timing parameters from
subnode of display-timings node, for displays supporting multiple
resolution, in case if a display supports single resolution, it fails
reading directly from display-timings node, to support it
ofnode_decode_panel_timing is added.

Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Use dot instead of comma. The fix doesn't affect anything but it is good to
be aligned with used pattern. The first is used only for string size
calculation and the second change is in the comment.

Fixes: db681d4929ca ("net: phy: Add new read ethernet phy id function")
Signed-off-by: Michal Simek <michal.simek@amd.com>

Add a function to copy properties from one node to another.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present ofnode_write_prop() is inconsistent between livetree and
flattree, in that livetree requires the caller to ensure the property
value is stable (e.g. in rodata or allocated) but flattree does not, since
it makes a copy.

This makes the API call a bit painful to use, since the caller must do
different things depending on OF_LIVE.

Add a new 'copy' argument which tells the function to make a copy if
needed. Add some tests to cover this behaviour.

Signed-off-by: Simon Glass <sjg@chromium.org>

We need to be able to look up phandles in any FDT, not just the control
FDT. Use the 'other' FDT to test this, with a helper function which gets
this as an oftree that can then we used as needed.

Add a few more tests and some comments at the top of the file, to explain
what is going on.

Signed-off-by: Simon Glass <sjg@chromium.org>

Add the logic to redirect requests for the device tree through a function
which can look up the tree ID. This works by using the top bits of
ofnode.of_offset to encode a tree.

It is assumed that there will only be a few device trees used at runtime,
typically the control FDT (always tree ID 0) and possibly a separate FDT
to be passed the OS.

The maximum number of device trees supported at runtime is 8, with this
implementation. That would use bits 30:28 of the node-offset value,
meaning that the positive offset range is limited to bits 27:0, versus
30:1 with this feature disabled. That still allows a device tree of up
to 256MB, which should be enough for most FITs. Larger ones can be
supported by using external data with the FIT, or by enabling OF_LIVE.

Update the documentation a little and fix up the comment for
ofnode_valid().

Signed-off-by: Simon Glass <sjg@chromium.org>

This function turns out to be a little confusing since it looks up a path
and also registers the tree. Split it into two, one that gets the root
node and one that looks up a path, so the purpose is clear.

Registering the tree will happen in a function to be added in a later
patch, called oftree_from_fdt().

Signed-off-by: Simon Glass <sjg@chromium.org>