| Age | Commit message (Collapse) | Author |
|---|
|
Add USB3 controller nodes including usb-core, resets, regulator, ss-phy
and hs-phy. This supports for LD20, PXs3 and the boards. This includes
additional efuse nodes for obtaining PHY trimming values.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Currently, the ethernet RGMII mode on the LD20 reference board is
unstable.
The default drive-strength of ethernet TX pins is too strong because
there is no dumping resistor on the TX lines on the board.
Weaken the drive-strength to make the ethernet more stable.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
According to Documentation/process/license-rules.rst, move the SPDX
License Identifier to the very top of the file. I used C++ comment
style not only for the SPDX line but for the entire block because
this seems Linus' preference [1]. I also dropped the parentheses to
follow the examples in that document.
[1] https://lkml.org/lkml/2017/11/25/133
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Add nodes of the AVE ethernet controller for LD11 and LD20 SoCs
and the boards.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
The dt-bindings header was applied to the driver subsystem. I had to
wait for a merge window to use it from DT.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
These were added to make the ARM64 branch self-contained because
updates for ARM and ARM64 are supposed to be sent as separate
pull requests.
Now, they were merged together in Linus' tree and interrupt-parent
from the arch/arm/boot/dts/uniphier-support-card.dtsi is visible from
ARM64 DT files by the cross-arch reference.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Interrupt lines from on-board devices are connected to the GPIO
controller. Add GPIO hogging so that the corresponding GPIO line
is automatically requested.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Interrupt lines from on-board devices are connected to the GPIO
controller. Handle this correctly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
To include dt-bindings headers.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Follow the recent trend for the license description, and fix the wrongly
stated X11 to MIT.
The X11 license text [1] is explicitly for the X Consortium and has a
couple of extra clauses. The MIT license text [2] is actually what the
current DT files claim.
[1] https://spdx.org/licenses/X11.html
[2] https://spdx.org/licenses/MIT.html
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
These UniPhier DT files are fine as long as they are compiled in the
Linux build system. It is true that Linux is the biggest user of
DT, but DT is project neutral from its concept. DT files are often
re-used for other projects. Especially for the UniPhier platform,
these DT files are re-used for U-Boot as well.
If I feed these DT files to the FDTGREP tool in U-Boot, it complains
about the node order.
FDTGREP spl/u-boot-spl.dtb
Error at 'fdt_find_regions': FDT_ERR_BADLAYOUT
/aliases node must come before all other nodes
Given that DT is not very sensitive to the order of nodes, this is a
problem of FDTGREP. I filed a bug report a year ago, but it has not
been fixed yet.
Differentiating DT is painful. So, I am up-streaming the requirement
from the down-stream project.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Fix warnings reported when built with W=1:
Node /memory has a reg or ranges property, but no unit name
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
All UniPhier device trees have the common prefix "uniphier-", so
"ph1-" is just making names longer. Recent documents and other
projects are not using PH1- prefixes any more.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
