| Message ID | 20221012055602.1544944-1-uwu@icenowy.me |
|---|---|
| Headers | show |
| Series | SUNIV USB and PopStick support (and updating mailmap) | expand |
On Wed, Oct 12, 2022, at 7:55 AM, Icenowy Zheng wrote: > Due to the SMTP provider adopted by AOSC applied some more restricted > rate limit that is not suitable for sending kernel patches, I switched > to a mailbox hosted on my own domain name now. In addition, there's a > single commit that is pushed to the mainline kernel tree during my > internship at Sipeed the last year. > > Map two AOSC mail addresses (both aosc.io and aosc.xyz domain names) and > a defunct Sipeed mail address to the new mail address. > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> I don't see a patch for updating the MAINTAINERS file here, if you haven't already sent that another way, you should probably change both at the same time. As a driver maintainer, you can also apply for a kernel.org account [https://korg.docs.kernel.org/accounts.html] and use that for sending patches and forwarding to another address. Arnd
在 2022-10-12星期三的 10:31 +0200，Arnd Bergmann写道： > On Wed, Oct 12, 2022, at 7:55 AM, Icenowy Zheng wrote: > > Due to the SMTP provider adopted by AOSC applied some more > > restricted > > rate limit that is not suitable for sending kernel patches, I > > switched > > to a mailbox hosted on my own domain name now. In addition, there's > > a > > single commit that is pushed to the mainline kernel tree during my > > internship at Sipeed the last year. > > > > Map two AOSC mail addresses (both aosc.io and aosc.xyz domain > > names) and > > a defunct Sipeed mail address to the new mail address. > > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > > I don't see a patch for updating the MAINTAINERS file here, if you > haven't already sent that another way, you should probably change > both at the same time. Good point. If this patchset is going to have a v3, I will contain it there; otherwise I will independently send it. > > As a driver maintainer, you can also apply for a kernel.org account > [https://korg.docs.kernel.org/accounts.html] and use that for > sending patches and forwarding to another address. Well I am in China now and not so easy to get my PGP key signed... > > Arnd
On Wed, Oct 12, 2022, at 10:35 AM, Icenowy Zheng wrote: > 在 2022-10-12星期三的 10:31 +0200，Arnd Bergmann写道： >> On Wed, Oct 12, 2022, at 7:55 AM, Icenowy Zheng wrote: >> >> I don't see a patch for updating the MAINTAINERS file here, if you >> haven't already sent that another way, you should probably change >> both at the same time. > > Good point. If this patchset is going to have a v3, I will contain it > there; otherwise I will independently send it. Ok. If you make a separate patch for the maintainers file, feel free to send this to me at soc@kernel.org, I can then put it into the fixes branch so it makes it into 6.1, otherwise I assume this gets picked up through the normal path along with the rest of the series. >> As a driver maintainer, you can also apply for a kernel.org account >> [https://korg.docs.kernel.org/accounts.html] and use that for >> sending patches and forwarding to another address. > > Well I am in China now and not so easy to get my PGP key signed... Right, that can be a problem. In an urgent case, you could probably do a video meeting with someone you've previously met that is already on the kernel keyring, but that is perhaps not worth the hassle if your current setup otherwise works fine. Arnd
Hi Icenowy, On Wed, 12 Oct 2022 at 07:57, Icenowy Zheng <uwu@icenowy.me> wrote: > > PopStick is a minimal Allwinner F1C200s dongle, with its USB controller > wired to a USB Type-A port, a SD slot and a SPI NAND flash on board, and > an on-board CH340 USB-UART converted connected to F1C200s's UART0. > > Add a device tree for it. As F1C200s is just F1C100s with a different > DRAM chip co-packaged, directly use F1C100s DTSI here. > > This commit covers the v1.1 version of this board, which is now shipped. > v1.0 is some internal sample that have not been shipped at all. > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > --- > New patch introduced in v2. > > arch/arm/boot/dts/Makefile | 3 +- > .../boot/dts/suniv-f1c200s-popstick-v1.1.dts | 101 ++++++++++++++++++ > 2 files changed, 103 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 6aa7dc4db2fc..0249c07bd8a6 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -1391,7 +1391,8 @@ dtb-$(CONFIG_MACH_SUN9I) += \ > sun9i-a80-optimus.dtb \ > sun9i-a80-cubieboard4.dtb > dtb-$(CONFIG_MACH_SUNIV) += \ > - suniv-f1c100s-licheepi-nano.dtb > + suniv-f1c100s-licheepi-nano.dtb \ > + suniv-f1c200s-popstick-v1.1.dtb > dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \ > tegra20-acer-a500-picasso.dtb \ > tegra20-asus-tf101.dtb \ > diff --git a/arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts b/arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts > new file mode 100644 > index 000000000000..121dfc6f609d > --- /dev/null > +++ b/arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts > @@ -0,0 +1,101 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > +/* > + * Copyright 2022 Icenowy Zheng <uwu@icenowy.me> > + */ > + > +/dts-v1/; > +#include "suniv-f1c100s.dtsi" > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/leds/common.h> > + > +/ { > + model = "Popcorn Computer PopStick v1.1"; > + compatible = "sourceparts,popstick-v1.1", "sourceparts,popstick", > + "allwinner,suniv-f1c200s", "allwinner,suniv-f1c100s"; > + > + aliases { > + mmc0 = &mmc0; > + serial0 = &uart0; > + spi0 = &spi0; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + leds { > + compatible = "gpio-leds"; > + > + led { > + function = LED_FUNCTION_STATUS; > + color = <LED_COLOR_ID_GREEN>; > + gpios = <&pio 4 6 GPIO_ACTIVE_HIGH>; /* PE6 */ > + linux,default-trigger = "heartbeat"; > + }; > + }; > + > + reg_vcc3v3: vcc3v3 { > + compatible = "regulator-fixed"; > + regulator-name = "vcc3v3"; > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3300000>; > + }; > +}; > + > +&mmc0 { > + cd-gpios = <&pio 4 3 GPIO_ACTIVE_LOW>; /* PE3 */ > + bus-width = <4>; > + disable-wp; > + status = "okay"; > + vmmc-supply = <®_vcc3v3>; > +}; > + > +&spi0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&spi0_pc_pins>; > + status = "okay"; > + > + flash@0 { > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "spi-nand"; > + reg = <0>; > + spi-max-frequency = <40000000>; > + > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "u-boot-with-spl"; > + reg = <0x0 0x100000>; > + }; > + > + ubi@100000 { > + label = "ubi"; > + reg = <0x100000 0x7f00000>; > + }; > + }; > + }; > +}; > + > +&otg_sram { Nitpick, but this should be alphabetically ordered no? > + status = "okay"; > +}; > + > +&uart0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&uart0_pe_pins>; > + status = "okay"; > +}; > + > +&usb_otg { > + dr_mode = "peripheral"; > + status = "okay"; > +}; > + > +&usbphy { > + status = "okay"; > +}; > -- > 2.37.1 > >
On 12/10/2022 01:56, Icenowy Zheng wrote: > PopStick is a minimal Allwinner F1C200s dongle, with its USB controller > wired to a USB Type-A port, a SD slot and a SPI NAND flash on board, and > an on-board CH340 USB-UART converted connected to F1C200s's UART0. (...) > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + leds { > + compatible = "gpio-leds"; > + > + led { > + function = LED_FUNCTION_STATUS; > + color = <LED_COLOR_ID_GREEN>; > + gpios = <&pio 4 6 GPIO_ACTIVE_HIGH>; /* PE6 */ > + linux,default-trigger = "heartbeat"; > + }; > + }; > + > + reg_vcc3v3: vcc3v3 { Generic node names, so at least generic "regulator" prefix or suffix. > + compatible = "regulator-fixed"; > + regulator-name = "vcc3v3"; > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3300000>; > + }; > +}; > + > +&mmc0 { > + cd-gpios = <&pio 4 3 GPIO_ACTIVE_LOW>; /* PE3 */ > + bus-width = <4>; > + disable-wp; > + status = "okay"; Keep status as last property. > + vmmc-supply = <®_vcc3v3>; > +}; > + > +&spi0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&spi0_pc_pins>; > + status = "okay"; > + > + flash@0 { > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "spi-nand"; > + reg = <0>; compatible and reg are by convention the first properties. > + spi-max-frequency = <40000000>; > + Best regards, Krzysztof
On 12/10/2022 01:55, Icenowy Zheng wrote: > Lichee Pi Nano has a Micro-USB connector, with its D+, D- pins connected > to the USB pins of the SoC and ID pin connected to PE2 GPIO. > > Enable the USB functionality. Use subject prefixes matching the subsystem (git log --oneline -- ...). This is a DTS change. > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > --- > No changes since v1. > > .../arm/boot/dts/suniv-f1c100s-licheepi-nano.dts | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > Best regards, Krzysztof
Hi Icenowy, Dne sreda, 12. oktober 2022 ob 07:55:56 CEST je Icenowy Zheng napisal(a): > The F1C100s SoC has one USB OTG port connected to a MUSB controller. > > Add support for its USB PHY. > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > --- > No changes since v1. > > drivers/phy/allwinner/phy-sun4i-usb.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c > b/drivers/phy/allwinner/phy-sun4i-usb.c index 3a3831f6059a..2f94cb77637b > 100644 > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > @@ -109,6 +109,7 @@ enum sun4i_usb_phy_type { > sun8i_v3s_phy, > sun50i_a64_phy, > sun50i_h6_phy, > + suniv_f1c100s_phy, > }; > > struct sun4i_usb_phy_cfg { > @@ -859,6 +860,14 @@ static int sun4i_usb_phy_probe(struct platform_device > *pdev) return 0; > } > > +static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = { > + .num_phys = 1, > + .type = suniv_f1c100s_phy, I think you should just use sun4i_a10_phy. It has no special handling. I don't see a point adding new phy types if there is no special cases for it. Best regards, Jernej > + .disc_thresh = 3, > + .phyctl_offset = REG_PHYCTL_A10, > + .dedicated_clocks = true, > +}; > + > static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = { > .num_phys = 3, > .type = sun4i_a10_phy, > @@ -988,6 +997,8 @@ static const struct of_device_id > sun4i_usb_phy_of_match[] = { { .compatible = > "allwinner,sun50i-a64-usb-phy", > .data = &sun50i_a64_cfg}, > { .compatible = "allwinner,sun50i-h6-usb-phy", .data = &sun50i_h6_cfg }, > + { .compatible = "allwinner,suniv-f1c100s-usb-phy", > + .data = &suniv_f1c100s_cfg }, > { }, > }; > MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match); > -- > 2.37.1
Hi Icenowy, Dne sreda, 12. oktober 2022 ob 07:55:57 CEST je Icenowy Zheng napisal(a): > The suniv SoC has a MUSB controller like the one in A33, but with a SRAM > region to be claimed. > > Add support for it. > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > --- > No changes since v1. > > drivers/usb/musb/sunxi.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c > index 7f9a999cd5ff..4b368d16a73a 100644 > --- a/drivers/usb/musb/sunxi.c > +++ b/drivers/usb/musb/sunxi.c > @@ -722,14 +722,17 @@ static int sunxi_musb_probe(struct platform_device > *pdev) INIT_WORK(&glue->work, sunxi_musb_work); > glue->host_nb.notifier_call = sunxi_musb_host_notifier; > > - if (of_device_is_compatible(np, "allwinner,sun4i-a10-musb")) > + if (of_device_is_compatible(np, "allwinner,sun4i-a10-musb") || > + of_device_is_compatible(np, "allwinner,suniv-f1c100s-musb")) { > set_bit(SUNXI_MUSB_FL_HAS_SRAM, &glue->flags); > + } > > if (of_device_is_compatible(np, "allwinner,sun6i-a31-musb")) > set_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags); > > if (of_device_is_compatible(np, "allwinner,sun8i-a33-musb") || > - of_device_is_compatible(np, "allwinner,sun8i-h3-musb")) { > + of_device_is_compatible(np, "allwinner,sun8i-h3-musb") || > + of_device_is_compatible(np, "allwinner,suniv-f1c100s-musb")) { All that should be eventually converted to quirks. But for now: Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Best regards, Jernej > set_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags); > set_bit(SUNXI_MUSB_FL_NO_CONFIGDATA, &glue->flags); > } > @@ -815,6 +818,7 @@ static const struct of_device_id sunxi_musb_match[] = { > { .compatible = "allwinner,sun6i-a31-musb", }, > { .compatible = "allwinner,sun8i-a33-musb", }, > { .compatible = "allwinner,sun8i-h3-musb", }, > + { .compatible = "allwinner,suniv-f1c100s-musb", }, > {} > }; > MODULE_DEVICE_TABLE(of, sunxi_musb_match); > -- > 2.37.1
在 2022-10-12星期三的 23:21 +0200，Jernej Škrabec写道： > Hi Icenowy, > > Dne sreda, 12. oktober 2022 ob 07:55:56 CEST je Icenowy Zheng > napisal(a): > > The F1C100s SoC has one USB OTG port connected to a MUSB > > controller. > > > > Add support for its USB PHY. > > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > > --- > > No changes since v1. > > > > drivers/phy/allwinner/phy-sun4i-usb.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c > > b/drivers/phy/allwinner/phy-sun4i-usb.c index > > 3a3831f6059a..2f94cb77637b > > 100644 > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > > @@ -109,6 +109,7 @@ enum sun4i_usb_phy_type { > > sun8i_v3s_phy, > > sun50i_a64_phy, > > sun50i_h6_phy, > > + suniv_f1c100s_phy, > > }; > > > > struct sun4i_usb_phy_cfg { > > @@ -859,6 +860,14 @@ static int sun4i_usb_phy_probe(struct > > platform_device > > *pdev) return 0; > > } > > > > +static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = { > > + .num_phys = 1, > > + .type = suniv_f1c100s_phy, > > I think you should just use sun4i_a10_phy. It has no special > handling. I don't > see a point adding new phy types if there is no special cases for it. Sounds reasonable, although I think we should finally drop .type and use only describing items. > > Best regards, > Jernej > > > + .disc_thresh = 3, > > + .phyctl_offset = REG_PHYCTL_A10, > > + .dedicated_clocks = true, > > +}; > > + > > static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = { > > .num_phys = 3, > > .type = sun4i_a10_phy, > > @@ -988,6 +997,8 @@ static const struct of_device_id > > sun4i_usb_phy_of_match[] = { { .compatible = > > "allwinner,sun50i-a64-usb-phy", > > .data = &sun50i_a64_cfg}, > > { .compatible = "allwinner,sun50i-h6-usb-phy", .data = > &sun50i_h6_cfg }, > > + { .compatible = "allwinner,suniv-f1c100s-usb-phy", > > + .data = &suniv_f1c100s_cfg }, > > { }, > > }; > > MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match); > > -- > > 2.37.1 > > >
Dne četrtek, 13. oktober 2022 ob 10:49:51 CEST je Icenowy Zheng napisal(a): > 在 2022-10-12星期三的 23:21 +0200，Jernej Škrabec写道： > > > Hi Icenowy, > > > > Dne sreda, 12. oktober 2022 ob 07:55:56 CEST je Icenowy Zheng > > > > napisal(a): > > > The F1C100s SoC has one USB OTG port connected to a MUSB > > > controller. > > > > > > Add support for its USB PHY. > > > > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > > > --- > > > No changes since v1. > > > > > > drivers/phy/allwinner/phy-sun4i-usb.c | 11 +++++++++++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c > > > b/drivers/phy/allwinner/phy-sun4i-usb.c index > > > 3a3831f6059a..2f94cb77637b > > > 100644 > > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > > > @@ -109,6 +109,7 @@ enum sun4i_usb_phy_type { > > > sun8i_v3s_phy, > > > sun50i_a64_phy, > > > sun50i_h6_phy, > > > + suniv_f1c100s_phy, > > > }; > > > > > > struct sun4i_usb_phy_cfg { > > > @@ -859,6 +860,14 @@ static int sun4i_usb_phy_probe(struct > > > platform_device > > > *pdev) return 0; > > > } > > > > > > +static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = { > > > + .num_phys = 1, > > > + .type = suniv_f1c100s_phy, > > > > I think you should just use sun4i_a10_phy. It has no special > > handling. I don't > > see a point adding new phy types if there is no special cases for it. > > Sounds reasonable, although I think we should finally drop .type and > use only describing items. That would be even better. Will you do it? > > > Best regards, > > Jernej > > > > > + .disc_thresh = 3, > > > + .phyctl_offset = REG_PHYCTL_A10, > > > + .dedicated_clocks = true, > > > +}; > > > + > > > static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = { > > > .num_phys = 3, > > > .type = sun4i_a10_phy, > > > @@ -988,6 +997,8 @@ static const struct of_device_id > > > sun4i_usb_phy_of_match[] = { { .compatible = > > > "allwinner,sun50i-a64-usb-phy", > > > .data = &sun50i_a64_cfg}, > > > { .compatible = "allwinner,sun50i-h6-usb-phy", .data = > > > > &sun50i_h6_cfg }, > > > > > + { .compatible = "allwinner,suniv-f1c100s-usb-phy", > > > + .data = &suniv_f1c100s_cfg }, > > > { }, > > > }; > > > MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match); > > > -- > > > 2.37.1
在 2022-10-13星期四的 20:25 +0200，Jernej Škrabec写道： > Dne četrtek, 13. oktober 2022 ob 10:49:51 CEST je Icenowy Zheng > napisal(a): > > 在 2022-10-12星期三的 23:21 +0200，Jernej Škrabec写道： > > > > > Hi Icenowy, > > > > > > Dne sreda, 12. oktober 2022 ob 07:55:56 CEST je Icenowy Zheng > > > > > > napisal(a): > > > > The F1C100s SoC has one USB OTG port connected to a MUSB > > > > controller. > > > > > > > > Add support for its USB PHY. > > > > > > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > > > > --- > > > > No changes since v1. > > > > > > > > drivers/phy/allwinner/phy-sun4i-usb.c | 11 +++++++++++ > > > > 1 file changed, 11 insertions(+) > > > > > > > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c > > > > b/drivers/phy/allwinner/phy-sun4i-usb.c index > > > > 3a3831f6059a..2f94cb77637b > > > > 100644 > > > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c > > > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c > > > > @@ -109,6 +109,7 @@ enum sun4i_usb_phy_type { > > > > sun8i_v3s_phy, > > > > sun50i_a64_phy, > > > > sun50i_h6_phy, > > > > + suniv_f1c100s_phy, > > > > }; > > > > > > > > struct sun4i_usb_phy_cfg { > > > > @@ -859,6 +860,14 @@ static int sun4i_usb_phy_probe(struct > > > > platform_device > > > > *pdev) return 0; > > > > } > > > > > > > > +static const struct sun4i_usb_phy_cfg suniv_f1c100s_cfg = { > > > > + .num_phys = 1, > > > > + .type = suniv_f1c100s_phy, > > > > > > I think you should just use sun4i_a10_phy. It has no special > > > handling. I don't > > > see a point adding new phy types if there is no special cases for > > > it. > > > > Sounds reasonable, although I think we should finally drop .type > > and > > use only describing items. > > That would be even better. Will you do it? At least not now. But I will at least drop suniv_f1c100s_phy in the next revision. > > > > > > Best regards, > > > Jernej > > > > > > > + .disc_thresh = 3, > > > > + .phyctl_offset = REG_PHYCTL_A10, > > > > + .dedicated_clocks = true, > > > > +}; > > > > + > > > > static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = { > > > > .num_phys = 3, > > > > .type = sun4i_a10_phy, > > > > @@ -988,6 +997,8 @@ static const struct of_device_id > > > > sun4i_usb_phy_of_match[] = { { .compatible = > > > > "allwinner,sun50i-a64-usb-phy", > > > > .data = &sun50i_a64_cfg}, > > > > { .compatible = "allwinner,sun50i-h6-usb-phy", .data = > > > > > > &sun50i_h6_cfg }, > > > > > > > + { .compatible = "allwinner,suniv-f1c100s-usb-phy", > > > > + .data = &suniv_f1c100s_cfg }, > > > > { }, > > > > }; > > > > MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match); > > > > -- > > > > 2.37.1 > >
On Wed, 12 Oct 2022 13:55:58 +0800 Icenowy Zheng <uwu@icenowy.me> wrote: Hi, > The suniv SoC has a USB OTG controller and a USB PHY like other > Allwinner SoCs. > > Add their device tree node. Looks alright to me, checked against the manual, also compared against some other Allwinner USB DT nodes. Also passes the binding and DTB checks. Just one small question below, but nevertheless: Reviewed-by: Andre Przywara <andre.przywara@arm.com> > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > --- > No changes since v1. > > arch/arm/boot/dts/suniv-f1c100s.dtsi | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/arch/arm/boot/dts/suniv-f1c100s.dtsi b/arch/arm/boot/dts/suniv-f1c100s.dtsi > index 0edc1724407b..a01541ba42c5 100644 > --- a/arch/arm/boot/dts/suniv-f1c100s.dtsi > +++ b/arch/arm/boot/dts/suniv-f1c100s.dtsi > @@ -133,6 +133,32 @@ mmc1: mmc@1c10000 { > #size-cells = <0>; > }; > > + usb_otg: usb@1c13000 { > + compatible = "allwinner,suniv-f1c100s-musb"; > + reg = <0x01c13000 0x0400>; > + clocks = <&ccu CLK_BUS_OTG>; > + resets = <&ccu RST_BUS_OTG>; > + interrupts = <26>; > + interrupt-names = "mc"; > + phys = <&usbphy 0>; > + phy-names = "usb"; > + extcon = <&usbphy 0>; > + allwinner,sram = <&otg_sram 1>; What is this "1" for? I see it all over the other Allwinner SRAM properties, but can't find any documentation about that number, nor can I see that it would be used in the code. Does anyone know? Cheers, Andre > + status = "disabled"; > + }; > + > + usbphy: phy@1c13400 { > + compatible = "allwinner,suniv-f1c100s-usb-phy"; > + reg = <0x01c13400 0x10>; > + reg-names = "phy_ctrl"; > + clocks = <&ccu CLK_USB_PHY0>; > + clock-names = "usb0_phy"; > + resets = <&ccu RST_USB_PHY0>; > + reset-names = "usb0_reset"; > + #phy-cells = <1>; > + status = "disabled"; > + }; > + > ccu: clock@1c20000 { > compatible = "allwinner,suniv-f1c100s-ccu"; > reg = <0x01c20000 0x400>;
On Wed, 12 Oct 2022 13:56:02 +0800 Icenowy Zheng <uwu@icenowy.me> wrote: Hi, > PopStick is a minimal Allwinner F1C200s dongle, with its USB controller > wired to a USB Type-A port, a SD slot and a SPI NAND flash on board, and > an on-board CH340 USB-UART converted connected to F1C200s's UART0. > > Add a device tree for it. As F1C200s is just F1C100s with a different > DRAM chip co-packaged, directly use F1C100s DTSI here. > > This commit covers the v1.1 version of this board, which is now shipped. > v1.0 is some internal sample that have not been shipped at all. As mentioned in the other patch, if that is the case, I don't think we need to bother about the version number in the filename and compatible strings, especially if a v1.0 will never be upstreamed. If there are users of the internal version still, they can use an explicit "v1.0" in their downstream versions. So apart from what Krzysztof and Clement already mentioned, the DT itself looks fine to me otherwise. I also ran dt-validate on it, and used it as a base for another F1C200s board. Cheers, Andre > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > --- > New patch introduced in v2. > > arch/arm/boot/dts/Makefile | 3 +- > .../boot/dts/suniv-f1c200s-popstick-v1.1.dts | 101 ++++++++++++++++++ > 2 files changed, 103 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 6aa7dc4db2fc..0249c07bd8a6 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -1391,7 +1391,8 @@ dtb-$(CONFIG_MACH_SUN9I) += \ > sun9i-a80-optimus.dtb \ > sun9i-a80-cubieboard4.dtb > dtb-$(CONFIG_MACH_SUNIV) += \ > - suniv-f1c100s-licheepi-nano.dtb > + suniv-f1c100s-licheepi-nano.dtb \ > + suniv-f1c200s-popstick-v1.1.dtb > dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \ > tegra20-acer-a500-picasso.dtb \ > tegra20-asus-tf101.dtb \ > diff --git a/arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts b/arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts > new file mode 100644 > index 000000000000..121dfc6f609d > --- /dev/null > +++ b/arch/arm/boot/dts/suniv-f1c200s-popstick-v1.1.dts > @@ -0,0 +1,101 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > +/* > + * Copyright 2022 Icenowy Zheng <uwu@icenowy.me> > + */ > + > +/dts-v1/; > +#include "suniv-f1c100s.dtsi" > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/leds/common.h> > + > +/ { > + model = "Popcorn Computer PopStick v1.1"; > + compatible = "sourceparts,popstick-v1.1", "sourceparts,popstick", > + "allwinner,suniv-f1c200s", "allwinner,suniv-f1c100s"; > + > + aliases { > + mmc0 = &mmc0; > + serial0 = &uart0; > + spi0 = &spi0; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + leds { > + compatible = "gpio-leds"; > + > + led { > + function = LED_FUNCTION_STATUS; > + color = <LED_COLOR_ID_GREEN>; > + gpios = <&pio 4 6 GPIO_ACTIVE_HIGH>; /* PE6 */ > + linux,default-trigger = "heartbeat"; > + }; > + }; > + > + reg_vcc3v3: vcc3v3 { > + compatible = "regulator-fixed"; > + regulator-name = "vcc3v3"; > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3300000>; > + }; > +}; > + > +&mmc0 { > + cd-gpios = <&pio 4 3 GPIO_ACTIVE_LOW>; /* PE3 */ > + bus-width = <4>; > + disable-wp; > + status = "okay"; > + vmmc-supply = <®_vcc3v3>; > +}; > + > +&spi0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&spi0_pc_pins>; > + status = "okay"; > + > + flash@0 { > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "spi-nand"; > + reg = <0>; > + spi-max-frequency = <40000000>; > + > + partitions { > + compatible = "fixed-partitions"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + partition@0 { > + label = "u-boot-with-spl"; > + reg = <0x0 0x100000>; > + }; > + > + ubi@100000 { > + label = "ubi"; > + reg = <0x100000 0x7f00000>; > + }; > + }; > + }; > +}; > + > +&otg_sram { > + status = "okay"; > +}; > + > +&uart0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&uart0_pe_pins>; > + status = "okay"; > +}; > + > +&usb_otg { > + dr_mode = "peripheral"; > + status = "okay"; > +}; > + > +&usbphy { > + status = "okay"; > +};
在 2022-10-24星期一的 15:16 +0100，Andre Przywara写道： > On Wed, 12 Oct 2022 13:55:58 +0800 > Icenowy Zheng <uwu@icenowy.me> wrote: > > Hi, > > > The suniv SoC has a USB OTG controller and a USB PHY like other > > Allwinner SoCs. > > > > Add their device tree node. > > Looks alright to me, checked against the manual, also compared > against > some other Allwinner USB DT nodes. Also passes the binding and DTB > checks. > > Just one small question below, but nevertheless: > > Reviewed-by: Andre Przywara <andre.przywara@arm.com> > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > > --- > > No changes since v1. > > > > arch/arm/boot/dts/suniv-f1c100s.dtsi | 26 > > ++++++++++++++++++++++++++ > > 1 file changed, 26 insertions(+) > > > > diff --git a/arch/arm/boot/dts/suniv-f1c100s.dtsi > > b/arch/arm/boot/dts/suniv-f1c100s.dtsi > > index 0edc1724407b..a01541ba42c5 100644 > > --- a/arch/arm/boot/dts/suniv-f1c100s.dtsi > > +++ b/arch/arm/boot/dts/suniv-f1c100s.dtsi > > @@ -133,6 +133,32 @@ mmc1: mmc@1c10000 { > > #size-cells = <0>; > > }; > > > > + usb_otg: usb@1c13000 { > > + compatible = "allwinner,suniv-f1c100s- > > musb"; > > + reg = <0x01c13000 0x0400>; > > + clocks = <&ccu CLK_BUS_OTG>; > > + resets = <&ccu RST_BUS_OTG>; > > + interrupts = <26>; > > + interrupt-names = "mc"; > > + phys = <&usbphy 0>; > > + phy-names = "usb"; > > + extcon = <&usbphy 0>; > > + allwinner,sram = <&otg_sram 1>; > > What is this "1" for? I see it all over the other Allwinner SRAM > properties, but can't find any documentation about that number, nor > can I > see that it would be used in the code. It means mapping the SRAM to dedicated device instead of CPU. This information is available in previous sunxi-sram.txt binding, but lost when converting to json schema, maybe because it does not fit well in json schema. > > Does anyone know? > > Cheers, > Andre > > > + status = "disabled"; > > + }; > > + > > + usbphy: phy@1c13400 { > > + compatible = "allwinner,suniv-f1c100s-usb- > > phy"; > > + reg = <0x01c13400 0x10>; > > + reg-names = "phy_ctrl"; > > + clocks = <&ccu CLK_USB_PHY0>; > > + clock-names = "usb0_phy"; > > + resets = <&ccu RST_USB_PHY0>; > > + reset-names = "usb0_reset"; > > + #phy-cells = <1>; > > + status = "disabled"; > > + }; > > + > > ccu: clock@1c20000 { > > compatible = "allwinner,suniv-f1c100s-ccu"; > > reg = <0x01c20000 0x400>; >