- Mar 02, 2018
-
-
Heiko Stuebner authored
This reverts commit c301b327 . While this works splendidly on rk3399-gru devices using the cros-ec extcon, other rk3399-based devices using the fusb302 or no power-delivery controller at all don't probe at all anymore, as the typec-phy currently always expects the extcon to be available and therefore defers probing indefinitly on these. Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Mar 01, 2018
-
-
Douglas Anderson authored
Back in the early days when gru devices were still under development we found an issue where the WiFi reset line needed to be configured as early as possible during the boot process to avoid the WiFi module being in a bad state. We found that the way to get the kernel to do this in the earliest possible place was to configure this line in the pinctrl hogs, so that's what we did. For some history here you can see <http://crosreview.com/368770>. After the time that change landed in the kernel, we landed a firmware change to configure this line even earlier. See <http://crosreview.com/399919>. However, even after the firmware change landed we kept the kernel change to deal with the fact that some people working on devices might take a little while to update their firmware. At this there are definitely zero devices out in the wild that have firmware without the fix in it. Specifically looking in the firmware branch several critically important fixes for memory stability landed after the patch in coreboot and I know we didn't ship without those. Thus, by now, everyone should have the new firmware and it's safe to not have the kernel set this up in a pinctrl hog. Historically, even though it wasn't needed to have this in a pinctrl hog, we still kept it since it didn't hurt. Pinctrl would apply the default hog at bootup and then would never touch things again. That all changed with commit 981ed1bf ("pinctrl: Really force states during suspend/resume"). After that commit then we'll re-apply the default hog at resume time and that can screw up the reset state of WiFi. ...and on rk3399 if you touch a device on PCIe in the wrong way then the whole system can go haywire. That's what was happening. Specifically you'd resume a rk3399-gru-* device and it would mostly resume, then would crash with some crazy weird crash. One could say, perhaps, that the recent pinctrl change was at fault (and should be fixed) since it changed behavior. ...but that's not really true. The device tree for rk3399-gru is really to blame. Specifically since the pinctrl is defined in the hog and not in the "wlan-pd-n" node then the actual user of this pin doesn't have a pinctrl entry for it. That's bad. Let's fix our problems by just moving the control of "wlan_module_reset_l pinctrl" out of the hog and put them in the proper place. NOTE: in theory, I think it should actually be possible to have a pin controlled _both_ by the hog and by an actual device. Once the device claims the pin I think the hog is supposed to let go. I'm not 100% sure that this works and in any case this solution would be more complex than is necessary. Reported-by:
Marc Zyngier <marc.zyngier@arm.com> Fixes: 48f4d979 ("arm64: dts: rockchip: add Gru/Kevin DTS") Fixes: 981ed1bf ("pinctrl: Really force states during suspend/resume") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Tested-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Feb 16, 2018
-
-
Robin Murphy authored
Trying to boot an RK3328 box with an HS200-capable eMMC, I see said eMMC fail to initialise as it can't run its tuning procedure, because the sample clock is missing. Upon closer inspection, whilst the clock is present in the DT, its name is subtly incorrect per the binding, so __of_clk_get_by_name() never finds it. By inspection, the drive clock suffers from a similar problem, so has never worked properly either. Fix up all instances of the incorrect clock names across the 64-bit DTs. Fixes: d717f735 ("arm64: dts: rockchip: add sdmmc/sdio/emmc nodes for RK3328 SoCs") Fixes: b790c2ca ("arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88 board") Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Feb 12, 2018
-
-
Yakir Yang authored
The pclk_vio_grf supply power for VIO GRF IOs, if it is disabled, driver would failed to operate the VIO GRF registers. The clock is optional but one of the side effects of don't have this clk is that the Samsung Chromebook Plus fails to recover display after a suspend/resume with following errors: rockchip-dp ff970000.edp: Input stream clock not detected. rockchip-dp ff970000.edp: Timeout of video streamclk ok rockchip-dp ff970000.edp: unable to config video Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> [this should also fix display failures when building rockchip-drm as module] Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Shawn Lin authored
The endpoint control gpio for rk3399-sapphire boards is gpio2_a4, so correct it now. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Kamil Trzciński authored
This commit enables thresh dma mode as this forces to disable checksuming, and chooses delay values which make the interface stable. These changes are needed, because ROCK64 is faced with two problems: 1. tx checksuming does not work with packets larger than 1498, 2. the default delays for tx/rx are not stable when using 1Gbps connection. Delays were found out with: https://github.com/ayufan-rock64/linux-build/tree/master/recipes/gmac-delays-test Signed-off-by:
Kamil Trzciński <ayufan@ayufan.eu> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Dec 20, 2017
-
-
Finley Xiao authored
This patch adds an efuse node in the device tree for rk3228 SoC. Signed-off-by:
Finley Xiao <finley.xiao@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Dec 17, 2017
-
-
Heiko Stuebner authored
Add the core gpu node for the rk3328, a Mali450MP2. Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
Rob Herring <robh@kernel.org>
-
Enric Balletbo i Serra authored
Enable tcphy and create the cros-ec's extcon node for the USB Type-C port. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Enric Balletbo i Serra authored
Add the usb3 phyter for the USB3.0 OTG controller. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Enric Balletbo i Serra authored
After commit '06c47e62 usb: dwc3: of-simple: Add support to get resets for the device' you can add the reset property to the dwc3 node, the reset is required for the controller to work properly, otherwise bind / unbind stress testing of the USB controller on rk3399 we'd often end up with lots of failures that looked like this: phy phy-ff800000.phy.9: phy poweron failed --> -110 dwc3 fe900000.dwc3: failed to initialize core dwc3: probe of fe900000.dwc3 failed with error -110 Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Enric Balletbo i Serra authored
The aclk_usb3 must be enabled to support USB3 for rk3399. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Enric Balletbo i Serra authored
Add the usb3 power-domain, its qos area and assign it to the usb device node. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Dec 06, 2017
-
-
Heiko Stuebner authored
It looks like either the current kernel or the hardware has reliability issues when the gmac is actually running at 1GBit. In my test-case it is not able to boot on a nfsroot at this speed, as the system will always lose the connection to the nfs-server during boot, before reaching any login prompt and not recover from this. So until this is solved, limit the speed to 100MBit as with this the nfsroot survives stress tests like an apt-get upgrade without problems. Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Klaus Goger authored
vdd_log has no consumer and therefore will not be set to a specific voltage. Still the PWM output pin gets configured and thence the vdd_log output voltage will changed from it's default. Depending on the idle state of the PWM this will slightly over or undervoltage the logic supply of the RK3399 and cause instability with GbE (undervoltage) and PCIe (overvoltage). Since the default value set by a voltage divider is the correct supply voltage and we don't need to change it during runtime we remove the rail from the devicetree completely so the PWM pin will not be configured. Signed-off-by:
Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Dec 05, 2017
-
-
Jeffy Chen authored
Add edp panel and enable related nodes on kevin. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by:
Mark Yao <mark.yao@rock-chips.com> Tested-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Heiko Stuebner authored
Probably due to some copy-paste mistake, the tsadc of rk3328 ended up with a 0 as 4th element that shouldn't be there, as interrupts on the rk3328 only have multiples of 3, making dtc complain. So remove it. Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Dec 04, 2017
-
-
Nickey Yang authored
We might include additional ports in derivative device trees, so the 'port' node should have an address, and the parent 'ports' node needs /#{addres,size}-cells. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Nickey Yang authored
This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Brian Norris authored
We've documented this one already, but we didn't add it to the DTSI yet. Suggested-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Nov 10, 2017
-
-
Masahiro Yamada authored
If CONFIG_OF_ALL_DTBS is enabled, "make ARCH=arm64 dtbs" compiles each DTB twice; one from arch/arm64/boot/dts/*/Makefile and the other from the dtb-$(CONFIG_OF_ALL_DTBS) line in arch/arm64/boot/dts/Makefile. It could be a race problem when building DTBS in parallel. Another minor issue is CONFIG_OF_ALL_DTBS covers only *.dts in vendor sub-directories, so this broke when Broadcom added one more hierarchy in arch/arm64/boot/dts/broadcom/<soc>/. One idea to fix the issues in a clean way is to move DTB handling to Kbuild core scripts. Makefile.dtbinst already recognizes dtb-y natively, so it should not hurt to do so. Add $(dtb-y) to extra-y, and $(dtb-) as well if CONFIG_OF_ALL_DTBS is enabled. All clutter things in Makefiles go away. As a bonus clean-up, I also removed dts-dirs. Just use subdir-y directly to traverse sub-directories. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> [robh: corrected BUILTIN_DTB to CONFIG_BUILTIN_DTB] Signed-off-by:
Rob Herring <robh@kernel.org>
-
- Nov 09, 2017
-
-
Masahiro Yamada authored
We need to add "clean-files" in Makfiles to clean up DT blobs, but we often miss to do so. Since there are no source files that end with .dtb or .dtb.S, so we can clean-up those files from the top-level Makefile. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Rob Herring <robh@kernel.org>
-
- Nov 02, 2017
-
-
Greg Kroah-Hartman authored
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by:
Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by:
Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 24, 2017
-
-
Romain Perier authored
This adds the definition for eFuse that is found on RK3368 SoCs with the corresponding data cells. Signed-off-by:
Romain Perier <romain.perier@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Oct 18, 2017
-
-
Jacob Chen authored
This patch add the RGA dt config of RK3399 SoC. Signed-off-by:
Jacob Chen <jacob-chen@iotwrt.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Arnd Bergmann authored
The latest dtc warns about an extraneous cell in the interrupt property of two of the iommu device nodes: Warning (interrupts_property): interrupts size is (16), expected multiple of 12 in /iommu@ff373f00 Warning (interrupts_property): interrupts size is (16), expected multiple of 12 in /iommu@ff900800 This removes the typo. Fixes: cede4c79 ("arm64: dts: rockchip: add rk3368 iommu nodes") Fixes: 49c82f2b ("arm64: dts: rockchip: add rk3328 iommu nodes") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Shawn Lin authored
The vcc_sd or vcc_sdio used for IO voltage for sdmmc and sdio interface on rk3399 platform have a limitation that it can't be larger than 3.0v, otherwise it has a potential risk for the chip. Correct all of them. Fixes: 171582e0 ("arm64: dts: rockchip: add support for firefly-rk3399 board") Fixes: 2c66fc34 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Fixes: 8164a84c ("arm64: dts: rockchip: Add support for rk3399 sapphire SOM") Cc: stable@vger.kernel.org Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Tested-by:
Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Oct 15, 2017
-
-
Pierre-Hugues Husson authored
Add a pinctrl setting to configure the cec pin to the correct function. Signed-off-by:
Pierre-Hugues Husson <phh@phh.me> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Pierre-Hugues Husson authored
Add the HDMI CEC controller main clock coming from the CRU. Signed-off-by:
Pierre-Hugues Husson <phh@phh.me> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Heinrich Schuchardt authored
The Firefly-RK3399 uses serial2 with 1,500,000 baud by default for communication in U-Boot and in the vendor provided distros. So let us set the same default in the Linux kernel. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Emil Renner Berthing authored
Adding the linux,gpio-keymap entry also has the side-effect of making the driver register the touchpad as a touchpad rather than another touchscreen. The index for BTN_LEFT was found by trial and error. Signed-off-by:
Emil Renner Berthing <kernel@esmil.dk> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Sep 26, 2017
-
-
Nickey Yang authored
The clk of grf must be enabled before writing grf register for rk3399. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> [the grf clock is already part of the binding since march 2017] Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Sep 20, 2017
-
-
Nickey Yang authored
There is a further gate in between the mipidphy reference clock and the actual ref-clock input to the dsi host, making the clock hirarchy look like clk_24m --> Gate11[14] --> clk_mipidphy_ref --> Gate21[0] --> clk_dphy_pll Fix the clock reference so that the whole clock subtree gets enabled when the dsi host needs it. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> [amended commit message] Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Sep 17, 2017
-
-
Heiko Stuebner authored
Enable the graphics-related nodes on the rk3399-firefly which makes it possible to see output on the on-board hdmi output. Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Jeffy Chen authored
Add rt5514 dsp of_node to codec list for Gru boards. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Liang Chen authored
RK3328 Evaluation Board use rk805 pmic, and one of the DCDCs in rk805 is for cpu regulator, assign the cpu regulator, so the cpufreq can work fine. Signed-off-by:
Liang Chen <cl@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Liang Chen authored
Rockchip's rk3328 evaluation board has 3 mmc controllers for sdio/sdmmc/emmc, let's enable them. Signed-off-by:
Liang Chen <cl@rock-chips.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
Heiko Stuebner authored
This reverts commit 6f2dea1f . Without accurate cpu regulators being set for boards this will wreak havoc when cpufreq-dt begins to set new frequencies without adjusting the core frequency. Additionally the rk3368 has an unsolved issue in that it has two separate cpu clusters with separate clock lines but only one cpu supply regulator for both clusters, which causes even more problems. While it seems that originally only one cluster was supposed to be active at a time (big or little), talking with real users of the hardware revealed that having all 8 cores accessible at 1.2GHz max is way more liked than having 4 cores at 1.5GHz max. Such an approach needs changes to cpufreq and/or opp though to control the two separate clock lines when setting both clusters to the same frequencies. In any case, having the OPPs in the dts at this point in time is undesireable, so remove them again for now. Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-
- Aug 30, 2017
-
-
Shawn Lin authored
Convert all RK3399 platforms to use per-lane PHY model in order to save more power by idling unused lane(s). Tested-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Brian Norris <briannorris@chromium.org>
-
- Aug 23, 2017
-
-
Klaus Goger authored
Haikou is a Qseven and μQseven baseboard featuring PCIe, USB3 and a video connector for MIPI-DSI/CSI and eDP adapter. This dts is for usage with the RK3399-Q7 SoM Puma. Signed-off-by:
Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de>
-