在 2022-10-25星期二的 16:44 +0100，Andre Przywara写道： > On Tue, 25 Oct 2022 23:30:26 +0800 > Icenowy Zheng <uwu@xxxxxxxxxx> wrote: > > Hi Icenowy, > > thanks for having a look! > And btw, forgot to mention in the cover letter: this relies on the > USB bits > in your series. Which works nicely, even in host mode. > > > 在 2022-10-25星期二的 15:59 +0100，Andre Przywara写道： > > > The Lctech Pi F1C200s (also previously known under the Cherry Pi > > > brand) > > > > Oh? Are they the same hardware? > > My board looks identical to this one: > https://www.cnx-software.com/2022/02/03/more-allwinner-f1c200s-arm9-boards-mangopi-r3-and-cherrypi-f1c200s/#cherrypi-f1c200s > > The only difference is the silkscreen, there is no cherry logo on > mine, > but the (no longer working) URL is the same, so it's the same board > from > the same company. I guess legal troubles? > > > > is a small development board with the Allwinner F1C200s SoC. This > > > is > > > the > > > same as the F1C100s, but with 64MB instead of 32MB co-packaged > > > DRAM. > > > > > > Alongside the obligatory micro-SD card slot, the board features a > > > SPI-NAND flash chip, LCD and touch connectors, and unpopulated > > > expansion header pins. > > > There are two USB Type-C ports on the board: One supplies the > > > power, > > > also > > > connects to the USB MUSB OTG controller port. The other one is > > > connected > > > to an CH340 USB serial chip, which in turn is connected to UART1. > > > > > > Add a devicetree file, so that the board can be used easily. > > > > > > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx> > > > --- > > > arch/arm/boot/dts/Makefile | 1 + > > > arch/arm/boot/dts/suniv-f1c100s.dtsi | 5 ++ > > > arch/arm/boot/dts/suniv-f1c200s-lctech-pi.dts | 80 > > > +++++++++++++++++++ > > > 3 files changed, 86 insertions(+) > > > create mode 100644 arch/arm/boot/dts/suniv-f1c200s-lctech-pi.dts > > > > > > diff --git a/arch/arm/boot/dts/Makefile > > > b/arch/arm/boot/dts/Makefile > > > index 6abf6434eb372..f99c5c20bf7ef 100644 > > > --- a/arch/arm/boot/dts/Makefile > > > +++ b/arch/arm/boot/dts/Makefile > > > @@ -1394,6 +1394,7 @@ dtb-$(CONFIG_MACH_SUN9I) += \ > > > sun9i-a80-cubieboard4.dtb > > > dtb-$(CONFIG_MACH_SUNIV) += \ > > > suniv-f1c100s-licheepi-nano.dtb \ > > > + suniv-f1c200s-lctech-pi.dtb \ > > > suniv-f1c200s-popstick-v1.1.dtb > > > dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \ > > > tegra20-acer-a500-picasso.dtb \ > > > diff --git a/arch/arm/boot/dts/suniv-f1c100s.dtsi > > > b/arch/arm/boot/dts/suniv-f1c100s.dtsi > > > index 0f24c766c9fc5..2ec022e92eea8 100644 > > > --- a/arch/arm/boot/dts/suniv-f1c100s.dtsi > > > +++ b/arch/arm/boot/dts/suniv-f1c100s.dtsi > > > @@ -201,6 +201,11 @@ uart0_pe_pins: uart0-pe-pins { > > > pins = "PE0", "PE1"; > > > function = "uart0"; > > > }; > > > + > > > + uart1_pa_pins: uart1-pa-pins { > > > + pins = "PA2", "PA3"; > > > + function = "uart1"; > > > + }; > > > > Should this be in a splitted commit? > > I don't know if this is really necessary, but am of course happy to > spin > this one out, if needed. > > > > }; > > > > > > timer@1c20c00 { > > > diff --git a/arch/arm/boot/dts/suniv-f1c200s-lctech-pi.dts > > > b/arch/arm/boot/dts/suniv-f1c200s-lctech-pi.dts > > > new file mode 100644 > > > index 0000000000000..a9d1778395438 > > > --- /dev/null > > > +++ b/arch/arm/boot/dts/suniv-f1c200s-lctech-pi.dts > > > @@ -0,0 +1,80 @@ > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > > > +/* > > > + * Copyright 2022 Arm Ltd, > > > + * based on work: > > > + * Copyright 2022 Icenowy Zheng <uwu@xxxxxxxxxx> > > > + */ > > > + > > > +/dts-v1/; > > > +#include "suniv-f1c100s.dtsi" > > > + > > > +#include <dt-bindings/gpio/gpio.h> > > > + > > > +/ { > > > + model = "Lctech Pi F1C200s"; > > > + compatible = "lctech,pi-f1c200s", "allwinner,suniv- > > > f1c200s", > > > + "allwinner,suniv-f1c100s"; > > > + > > > + aliases { > > > + mmc0 = &mmc0; > > > + serial0 = &uart1; > > > + spi0 = &spi0; > > > + }; > > > + > > > + chosen { > > > + stdout-path = "serial0:115200n8"; > > > + }; > > > + > > > + reg_vcc3v3: regulator-3v3 { > > > + compatible = "regulator-fixed"; > > > + regulator-name = "vcc3v3"; > > > + regulator-min-microvolt = <3300000>; > > > + regulator-max-microvolt = <3300000>; > > > + }; > > > +}; > > > + > > > +&mmc0 { > > > + broken-cd; > > > + bus-width = <4>; > > > + disable-wp; > > > + vmmc-supply = <®_vcc3v3>; > > > + status = "okay"; > > > +}; > > > + > > > +&otg_sram { > > > + status = "okay"; > > > +}; > > > + > > > +&spi0 { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&spi0_pc_pins>; > > > + status = "okay"; > > > + > > > + flash@0 { > > > + compatible = "spi-nand"; > > > + reg = <0>; > > > + #address-cells = <1>; > > > + #size-cells = <1>; > > > + spi-max-frequency = <40000000>; > > > + }; > > > +}; > > > + > > > +&uart1 { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&uart1_pa_pins>; > > > + status = "okay"; > > > +}; > > > + > > > +/* > > > + * This is a Type-C socket, but CC1/2 are not connected, and > > > VBUS is > > > connected > > > + * to Vin, which supplies the board. Host mode works (if the > > > board > > > is powered > > > + * otherwise), but peripheral is probably the intention. > > > + */ > > > +&usb_otg { > > > + dr_mode = "peripheral"; > > > + status = "okay"; > > > +}; > > > > Finally we should get able to override dr_mode just by HW. > > Do you mean by software? Yeah, that would be useful. Otherwise one > could Yes, by SW. It's a typo (I think it's some kind of nerve link bit-flip when I was typing this). BTW I think the further utilization of something like a proper Type-C controller (e.g. FUSB302) needs the driver to implement a new interface in kernel, usb role switch. > dedicate a GPIO to a fake ID_DET pin, I guess. Or use a DT overlay. > > Cheers, > Andre > > > > + > > > +&usbphy { > > > + status = "okay"; > > > +}; > > >
