- Feb 01, 2021
-
-
Maxime Ripard authored
DTC and the dt-validate tools report warnings for opp with the format opp@$frequency: dtc for a missing reg property, and dt-validate since the binding requires child nodes to have the format opp-$frequency. Change this to the latter format. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Jernej Skrabec <jernej.skrabec@siol.net> Link: https://lore.kernel.org/r/20210114113538.1233933-16-maxime@cerno.tech
-
Maxime Ripard authored
The SinA33 panel is missing its power-supply property, even though the binding mandates it. Signed-off-by:
-
Maxime Ripard authored
The empty CSI port triggers a dt-validate warning. Let's align with the other DTSI and remove it entirely, expecting the DTS to fill it. Signed-off-by:
-
Maxime Ripard authored
Our CSI endpoint trigger some DTC warnings due to the fact that we're having a single endpoint that doesn't need any reg property, and since we don't have a reg property, we don't need the address-cells and size-cells properties anymore. Fix those Signed-off-by:
-
Maxime Ripard authored
While the USB PHY Device Tree mandates that the name of the ID detect pin should be usb0_id_det-gpios, a significant number of device tree use usb0_id_det-gpio instead. This was functional because the GPIO framework falls back to the gpio suffix that is legacy, but we should fix this. Signed-off-by:
-
Maxime Ripard authored
Even though it translates to the same thing down to the binary level, we should have an array of 2 number cells to describe each voltage state, which in turns create a validation warning. Let's fix this. Signed-off-by:
-
Maxime Ripard authored
The mma8452 binding doesn't expect an io-channel-cells property, let's remove it. Signed-off-by:
-
- Jan 18, 2021
-
-
Maxime Ripard authored
The CPU thermal zone is called on most of the older DTSI cpu_thermal. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it. Signed-off-by:
-
Maxime Ripard authored
The pwm-backlight binding requires a power supply. Make sure we provide one. Signed-off-by:
-
Maxime Ripard authored
According to the LED bindings, the LED node names are supposed to be led plus an optional suffix. Let's fix our users to use that new scheme. Signed-off-by:
-
Maxime Ripard authored
The commit ec98a875 ("rtc: sun6i: Make external 32k oscillator optional") loosened the requirement of the clocks property, making it optional. However, the binding still required it to be present. Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Fixes: ec98a875 ("rtc: sun6i: Make external 32k oscillator optional") Signed-off-by:
-
Maxime Ripard authored
The AXP803 compatible was introduced recently with a fallback to the AXP813, but it was never documented. Cc: Jonathan Cameron <jic23@kernel.org> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20210114113538.1233933-2-maxime@cerno.tech
-
Maxime Ripard authored
Commit 6ab48105 ("ARM: dts: s3: pinecube: align compatible property to other S3 boards") changed the pinecube compatible to make it similar to the other S3 boards we have, but failed to update the bindings documentation. Fixes: 6ab48105 ("ARM: dts: s3: pinecube: align compatible property to other S3 boards") Signed-off-by:
-
Paul Kocialkowski authored
This adds a device-tree definition for the CSI0 MCLK pin, which can be used for feeding MIPI CSI-2 sensors. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Signed-off-by:
-
Samuel Holland authored
The H6 SoC contains an undocumented but fully functional RSB controller. Add support for it. The MMIO register address matches other SoCs of the same generation, and the IRQ matches a hole in the documented IRQ list. Signed-off-by:
Samuel Holland <samuel@sholland.org> Acked-by:
Maxime Ripard <mripard@kernel.org> [wens@csie.org: Use raw numbers instead of macros for clock/reset index] Signed-off-by:
-
- Jan 14, 2021
-
-
Andre Przywara authored
The eMMC modules offered for the Pine64 boards are capable of the HS200 eMMC speed mode, when observing the frequency limit of 150 MHz. Enable that in the DT. This increases the interface speed from ~80 MB/s to ~120 MB/s. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
-
Andre Przywara authored
The eMMC modules offered for the Pine64 boards are capable of the HS200 eMMC speed mode, when observing the frequency limit of 150 MHz. Enable that in the DT. This increases the interface speed from ~80 MB/s to ~120 MB/s. Signed-off-by:
-
Andre Przywara authored
In contrast to the H6 (and later) manuals, the A64 datasheet does not specify any limitations in the maximum possible frequency for eMMC controllers. However experimentation has found that a 150 MHz limit similar to other SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist for the MMC2 controller. Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi. The Pinebook seems to be the an odd exception, since it apparently seems to work with 200 MHz as well, so overwrite this in its board .dts file. Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works. Fixes: 22be992f ("arm64: allwinner: a64: Increase the MMC max frequency") Signed-off-by:
-
Andre Przywara authored
The H6 manual explicitly lists a frequency limit of 150 MHz for the bus frequency of the MMC controllers. So far we had no explicit limits in the DT, which limited eMMC to the spec defined frequencies, or whatever the driver defines (both Linux and FreeBSD use 52 MHz here). Put those maximum frequencies in the SoC .dtsi, to allow higher speed modes (which still would need to be explicitly enabled, per board). Tested with an eMMC using HS-200 on a Pine H64. Running at the spec'ed 200 MHz indeed fails with I/O errors, but 150 MHz seems to work stably. Fixes: 8f54bd15 ("arm64: allwinner: h6: add device tree nodes for MMC controllers") Signed-off-by:
-
Andre Przywara authored
The SD card on the SoPine SoM module is somewhat concealed, so was originally defined as "non-removable". However there is a working card-detect pin (tested on two different SoM versions), and in certain SoM base boards it might be actually accessible at runtime. Also the Pine64-LTS shares the SoPine base .dtsi, so inherited the non-removable flag, even though the SD card slot is perfectly accessible and usable there. (It turns out that just *my* board has a broken card detect switch, so I originally thought CD wouldn't work on the LTS.) Drop the "non-removable" flag to describe the SD card slot properly. Fixes: c3904a26 ("arm64: allwinner: a64: add DTSI file for SoPine SoM") Signed-off-by:
-
Andre Przywara authored
The Pine64-LTS board features a blue status LED on pin PL7. Describe it in the DT. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by:
-
Andre Przywara authored
In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the H6 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: eabb3d42 ("arm64: dts: allwinner: h6: add USB2-related device nodes") Signed-off-by:
-
Andre Przywara authored
In recent Allwinner SoCs the first USB host controller (HCI0) shares the first PHY with the MUSB controller. Probably to make this sharing work, we were avoiding to declare this in the DT. This has two shortcomings: - U-Boot (which uses the same .dts) cannot use this port in host mode without a PHY linked, so we were loosing one USB port there. - It requires the MUSB driver to be enabled and loaded, although we don't actually use it. To avoid those issues, let's add this PHY link to the A64 .dtsi file. After all PHY port 0 *is* connected to HCI0, so we should describe it as this. Remove the part from the Pinebook DTS which already had this property. This makes it work in U-Boot, also improves compatiblity when no MUSB driver is loaded (for instance in distribution installers). Fixes: dc03a047 ("arm64: allwinner: a64: add EHCI0/OHCI0 nodes to A64 DTSI") Signed-off-by:
-
- Jan 13, 2021
-
-
Jernej Skrabec authored
PineH64 model B has wifi+bt combo module. Wifi is already supported, so lets add also bluetooth node. Signed-off-by:
-
Samuel Holland authored
PinePhone volume keys are connected to the LRADC in the A64. Users may want to use them to wake the device from sleep. Support this by declaring the LRADC as a wakeup source. Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Sergio Sota authored
The A10s/A13 mali gpu was not defined in device tree Add A10 mali gpu as a fallback for A10s/A13 Tested with Olimex-A13-SOM / Olimex-A13-OlinuXino-MICRO "kmscube" 3d cube on screen (60fps / 10%cpu) Versions: Lima:1.1.0 EGL:1.4 OpenGLES:2.0 Mesa:20.2.2 Signed-off-by:
Sergio Sota <sergiosota@fanamoel.com> Signed-off-by:
-
- Jan 07, 2021
-
-
Jernej Skrabec authored
Deinterlace core is completely compatible to H3. Add a node for it. Signed-off-by:
-
Jernej Skrabec authored
R40 contains deinterlace core compatible to that in H3. One peculiarity is that RAM gate is shared with CSI1. User manual states it's separate but that's not true. Shared gate was verified with BSP Linux code check and with runtime tests (CPU crashed if CSI1 gate was not ungated). Signed-off-by:
-
Jernej Skrabec authored
Allwinner R40 SoC also contains deinterlace core, compatible to H3. Add compatible string for it. Signed-off-by:
-
Dylan Van Assche authored
All revisions of the PinePhone share most of the hardware. This patch makes it easier to detect PinePhone hardware without having to check for each possible revision. Signed-off-by:
Dylan Van Assche <me@dylanvanassche.be> Signed-off-by:
-
Icenowy Zheng authored
As the original PineTab DT (which uses sun50i-a64-pinetab name) is only for development samples, document this. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Signed-off-by:
-
Icenowy Zheng authored
PineTabs since Early Adopter batch will use a new LCD panel. Add device tree for PineTab with the new panel. Signed-off-by:
-
Icenowy Zheng authored
Early adopter's PineTabs (and further releases) will have a new LCD panel different with the one that is used when in development (because the old panel's supply discontinued). Add a new DT compatible for it. Signed-off-by:
-
Michael Klein authored
Add add devicetree information for the regulator-poweroff driver. Signed-off-by:
Michael Klein <michael@fossekall.de> Signed-off-by:
-
Paul Kocialkowski authored
The SL631 is a family of Allwinner V3 action cameras sold under various names, such as SJCAM SJ4000 Air or F60 Action Camera. Devices in this family share a common board design but can be found with different image sensors, including the IMX179 and the OV4689. This adds support for a common dtsi for the SL631 family as well as a specific dts for the IMX179 fashion, which will later be populated with an IMX179 node when a driver is available. Features that were tested on the device include: - UART debug - MMC - USB peripheral (e.g. g_ether) - Buttons - SPI NOR flash Note that the exact designer/vendor of these boards is unknown. Signed-off-by:
-
Paul Kocialkowski authored
This adds documentation for the compatible strings of the SL631 Action Camera with IMX179. Note that the device is sold under various different names, such as the SJCAM SJ4000 Air or F60 Action Camera. This is a similar situation to the Q8 tablets and just like them, the allwinner vendor is used as fallback. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201206165131.1041983-5-contact@paulk.fr
-
Paul Kocialkowski authored
This fixes a few things with the Pinecube AXP209 node: - No compatible is required since it is using an AXP209 (not AXP203) according to the schematics and this is what the included axp209.dtsi already has; - The interrupt-controller and #interrupt-cells properties are already described in the included axp209.dtsi; - The interrupt comes through the NMI controller, not directly through the GIC. Signed-off-by:
-
Paul Kocialkowski authored
The V3s/V3 has a NMI interrupt controller, mainly used for the AXP209. Its address follows the system controller block, which was previously incorrectly described as spanning over 0x1000 address bytes. Even though this is what the Allwinner documentation indicates, precedence from other SoCs such as the R40 suggests that this is not actually the case. This reduces the system controller address span up to the NMI controller and adds a node for the controller, with its dedicated compatible. While the interrupt number was found in Allwinner's documentation, the address for the controller is specified in any Allwinner SDK supporting sun8iw8 (V3/V3s) at: drivers/power/axp_power/axp20/axp20-board.c It was tested to work on a V3 board with an AXP209 connected to the NMI interrupt line. Signed-off-by:
-
Paul Kocialkowski authored
The V3s NMI controller seems register-compatible with the A80 (sun9i). Add new items for the compatible string, with an entry specific to the V3s and the A80 entry. Acked-by:
-
- Jan 04, 2021
-
-
Michael Klein authored
Add gpio-line-names as documented on gitbooks [1] and in the schematics [2]. [1]: https://bananapi.gitbook.io/bpi-m2/en/bpi-m2_gpio_pin_define [2]: https://drive.google.com/file/d/0B4PAo2nW2KfnRERWNnJGSGxJbmM/view Signed-off-by:
-
