[linux-sunxi] Re: [PATCH 7/8] [DO NOT MERGE, DIRTY HACK] sunxi: use UBI for environement storage
在 2022-10-14星期五的 11:05 +0800，Icenowy Zheng写道：
> Signed-off-by: Icenowy Zheng
By the way should we have some better way to handle the placement of
environments?
> ---
> board/sunxi/board.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 21a2407e06..f4138573d4 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -133,6 +133,7 @@ void i2c_init_board(void)
> */
> enum env_location env_get_location(enum env_operation op, int prio)
> {
> + return prio ? ENVL_UNKNOWN : ENVL_UBI;
> if (prio > 1)
> return ENVL_UNKNOWN;
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/9089677fb289e93aa51089189ac02e249e4638a1.camel%40icenowy.me.
[linux-sunxi] Re: [PATCH 3/8] sunxi: SPL SPI: allow multiple boot attempt
于 2023年1月15日 GMT+08:00 上午3:56:08, Samuel Holland 写到:
>On 10/13/22 22:05, Icenowy Zheng wrote:
>> As we're going to add support for SPI NAND to this code, add code that
>> allows multiple boot attempts with different load offsets and functions.
>>
>> To keep compatibility with loading raw binary on SPI NOR, a bool
>> parameter is used to allow booting without valid magic number when
>> booting with SPI NOR.
>
>So the issue is that when CONFIG_SPL_RAW_IMAGE_SUPPORT=y, then
>spl_parse_image_header() will return 0 even when using the wrong NAND
>parameters? I don't see a better solution, so:
Good point, maybe the next patch needs to add some dependency
of raw image support to SPI NAND support option.
>
>Reviewed-by: Samuel Holland
>Tested-by: Samuel Holland # Orange Pi Zero Plus
>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm/mach-sunxi/spl_spi_sunxi.c | 58 +++--
>> 1 file changed, 38 insertions(+), 20 deletions(-)
>>
>> diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> b/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> index 88c15a3ee9..21be33a23f 100644
>> --- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> +++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
>> @@ -340,8 +340,8 @@ static void spi0_read_data(void *buf, u32 addr, u32 len,
>> u32 addr_len)
>> }
>> }
>>
>> -static ulong spi_load_read(struct spl_load_info *load, ulong sector,
>> - ulong count, void *buf)
>> +static ulong spi_load_read_nor(struct spl_load_info *load, ulong sector,
>> + ulong count, void *buf)
>> {
>> spi0_read_data(buf, sector, count, 3);
>>
>> @@ -350,41 +350,59 @@ static ulong spi_load_read(struct spl_load_info *load,
>> ulong sector,
>>
>>
>> /*/
>>
>> -static int spl_spi_load_image(struct spl_image_info *spl_image,
>> - struct spl_boot_device *bootdev)
>> +static int spl_spi_try_load(struct spl_image_info *spl_image,
>> +struct spl_boot_device *bootdev,
>> +struct spl_load_info *load, u32 offset,
>> +bool allow_raw)
>> {
>> int ret = 0;
>> struct legacy_img_hdr *header;
>> -uint32_t load_offset = sunxi_get_spl_size();
>> -
>
>nit: keep this blank line
>
>> header = (struct legacy_img_hdr *)CONFIG_SYS_TEXT_BASE;
>> -load_offset = max_t(uint32_t, load_offset, CONFIG_SYS_SPI_U_BOOT_OFFS);
>> -
>> -spi0_init();
>>
>> -spi0_read_data((void *)header, load_offset, 0x40, 3);
>> +if (load->read(load, offset, 0x40, (void *)header) == 0)
>> +return -EINVAL;
>>
>> if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
>> image_get_magic(header) == FDT_MAGIC) {
>> -struct spl_load_info load;
>>
>> debug("Found FIT image\n");
>> -load.dev = NULL;
>> -load.priv = NULL;
>> -load.filename = NULL;
>> -load.bl_len = 1;
>> -load.read = spi_load_read;
>> -ret = spl_load_simple_fit(spl_image, &load,
>> - load_offset, header);
>> +ret = spl_load_simple_fit(spl_image, load,
>> + offset, header);
>> } else {
>> +if (!allow_raw && image_get_magic(header) != IH_MAGIC)
>> +return -EINVAL;
>> +
>> ret = spl_parse_image_header(spl_image, bootdev, header);
>> if (ret)
>> return ret;
>>
>> -spi0_read_data((void *)spl_image->load_addr,
>> - load_offset, spl_image->size, 3);
>> +if (load->read(load, offset, spl_image->size,
>> + (void *)spl_image->load_addr) == 0)
>> +ret = -EINVAL;
>> }
>>
>> +return ret;
>> +}
>> +
>> +static int spl_spi_load_image(struct spl_image_info *spl_image,
>> + struct spl_boot_device *bootdev)
>> +{
>> +int ret = 0;
>> +uint32_t load_offset = sunxi_get_spl_size();
>> +struct spl_load_info load;
>> +
>> +load_offset = max_t(uint32_t, load_offset, CONFIG_SYS_SPI_U_BOOT_OFFS);
>> +
>> +load.dev = NULL;
>> +load.priv = NULL;
>> +load.filename = NULL;
>> +load.bl_len = 1;
>> +
>> +spi0_init();
>> +
>> +load.read = spi_load_read_nor;
>> +ret = spl_spi_try_load(spl_image, bootdev, &load, load_offset, true);
>> +
>> spi0_deinit();
>>
>> return ret;
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/88485C75-A6D1-44D2-89EC-8A67A0E8A056%40icenowy.me.
[linux-sunxi] [PATCH 7/8] [DO NOT MERGE, DIRTY HACK] sunxi: use UBI for environement storage
Signed-off-by: Icenowy Zheng
---
board/sunxi/board.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 21a2407e06..f4138573d4 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -133,6 +133,7 @@ void i2c_init_board(void)
*/
enum env_location env_get_location(enum env_operation op, int prio)
{
+ return prio ? ENVL_UNKNOWN : ENVL_UBI;
if (prio > 1)
return ENVL_UNKNOWN;
--
2.37.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20221014030520.3067228-8-uwu%40icenowy.me.
[linux-sunxi] [PATCH 6/8] [DO NOT MERGE] sunxi: sync DT from my tree for PopStick
Signed-off-by: Icenowy Zheng
---
arch/arm/dts/Makefile| 3 +-
arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 16 +++
arch/arm/dts/suniv-f1c100s.dtsi | 26 +
arch/arm/dts/suniv-f1c200s-popstick-v1.1.dts | 101 +++
4 files changed, 145 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/suniv-f1c200s-popstick-v1.1.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9b00b64509..ef7fff3559 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -529,7 +529,8 @@ dtb-$(CONFIG_STM32H7) += stm32h743i-disco.dtb \
stm32h750i-art-pi.dtb
dtb-$(CONFIG_MACH_SUNIV) += \
- suniv-f1c100s-licheepi-nano.dtb
+ suniv-f1c100s-licheepi-nano.dtb \
+ suniv-f1c200s-popstick-v1.1.dtb
dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-a1000.dtb \
sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
index 04e59b8381..1935d8c885 100644
--- a/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
+++ b/arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
@@ -6,6 +6,8 @@
/dts-v1/;
#include "suniv-f1c100s.dtsi"
+#include
+
/ {
model = "Lichee Pi Nano";
compatible = "licheepi,licheepi-nano", "allwinner,suniv-f1c100s";
@@ -50,8 +52,22 @@
};
};
+&otg_sram {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pe_pins>;
status = "okay";
};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpio = <&pio 4 2 GPIO_ACTIVE_HIGH>; /* PE2 */
+ status = "okay";
+};
diff --git a/arch/arm/dts/suniv-f1c100s.dtsi b/arch/arm/dts/suniv-f1c100s.dtsi
index bc563c12e9..6d7b120da2 100644
--- a/arch/arm/dts/suniv-f1c100s.dtsi
+++ b/arch/arm/dts/suniv-f1c100s.dtsi
@@ -133,6 +133,32 @@
#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>;
+ 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@1c2 {
compatible = "allwinner,suniv-f1c100s-ccu";
reg = <0x01c2 0x400>;
diff --git a/arch/arm/dts/suniv-f1c200s-popstick-v1.1.dts
b/arch/arm/dts/suniv-f1c200s-popstick-v1.1.dts
new file mode 100644
index 00..121dfc6f60
--- /dev/null
+++ b/arch/arm/dts/suniv-f1c200s-popstick-v1.1.dts
@@ -0,0 +1,101 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022 Icenowy Zheng
+ */
+
+/dts-v1/;
+#include "suniv-f1c100s.dtsi"
+
+#include
+#include
+
+/ {
+ 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 = ;
+ gpios = <&pio 4 6 GPIO_ACTIVE_HIGH>; /* PE6 */
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "
[linux-sunxi] [PATCH 5/8] sunxi: enable support for SPI NAND booting on SUNIV
As we added support for SPI NAND to the existing SPL SPI codepath, route
the boot code to it when it detects the BROM loads SPL from SPI NAND, as
for SoCs with both SPI NAND and boot media indicator support, the boot
media indicator is the same for SPI NOR and NAND.
Signed-off-by: Icenowy Zheng
---
arch/arm/mach-sunxi/board.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 220ed80ba7..3a81743e8f 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -210,12 +210,10 @@ static int suniv_get_boot_source(void)
case SUNIV_BOOTED_FROM_MMC0:
return SUNXI_BOOTED_FROM_MMC0;
case SUNIV_BOOTED_FROM_SPI:
+ case SUNIV_BOOTED_FROM_NAND:
return SUNXI_BOOTED_FROM_SPI;
case SUNIV_BOOTED_FROM_MMC1:
return SUNXI_BOOTED_FROM_MMC2;
- /* SPI NAND is not supported yet. */
- case SUNIV_BOOTED_FROM_NAND:
- return SUNXI_INVALID_BOOT_SOURCE;
}
/* If we get here something went wrong try to boot from FEL.*/
printf("Unknown boot source from BROM: 0x%x\n", brom_call);
--
2.37.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20221014030520.3067228-6-uwu%40icenowy.me.
[linux-sunxi] [PATCH 8/8] [DO NOT MERGE] sunxi: add a defconfig for PopStick
--- configs/popstick_defconfig | 35 +++ 1 file changed, 35 insertions(+) create mode 100644 configs/popstick_defconfig diff --git a/configs/popstick_defconfig b/configs/popstick_defconfig new file mode 100644 index 00..6dc21695b7 --- /dev/null +++ b/configs/popstick_defconfig @@ -0,0 +1,35 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SYS_MALLOC_LEN=0x12 +CONFIG_ENV_SIZE=0x1f000 +CONFIG_DEFAULT_DEVICE_TREE="suniv-f1c200s-popstick-v1.1" +CONFIG_SPL=y +CONFIG_MACH_SUNIV=y +CONFIG_DRAM_CLK=156 +CONFIG_DRAM_ZQ=0 +CONFIG_SUNXI_MINIMUM_DRAM_MB=64 +CONFIG_MMC0_CD_PIN="PE3" +# CONFIG_VIDEO_SUNXI is not set +CONFIG_SPL_SPI_SUNXI=y +CONFIG_SPL_SPI_SUNXI_NAND=y +CONFIG_SPL_SPI_SUNXI_NAND_ASSUMED_PAGESIZE=0x800 +CONFIG_SPL_STACK=0x8000 +CONFIG_SYS_SPI_U_BOOT_OFFS=0x2 +CONFIG_CMD_MTD=y +# CONFIG_CMD_SF is not set +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_UBI=y +# CONFIG_ENV_IS_IN_FAT is not set +# CONFIG_ENV_IS_IN_SPI_FLASH is not set +CONFIG_ENV_IS_IN_UBI=y +CONFIG_ENV_UBI_PART="ubi" +CONFIG_ENV_UBI_VOLUME="env" +# CONFIG_NET is not set +CONFIG_MTD=y +CONFIG_DM_MTD=y +CONFIG_MTD_SPI_NAND=y +# CONFIG_SPI_FLASH is not set +CONFIG_SF_DEFAULT_SPEED=2500 +# CONFIG_UBI_SILENCE_MSG is not set +CONFIG_SPI=y +# CONFIG_UBIFS_SILENCE_MSG is not set -- 2.37.1 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20221014030520.3067228-9-uwu%40icenowy.me.
[linux-sunxi] [PATCH 0/8] SUNIV SPI NAND support in SPL
This patchset tries to extend SPI-based boot code in sunxi SPL to support SPI NAND, following the same principle with current SPI NOR code (mimicking the behavior of sunxi BROM). In addition, as part of test to this patchset, some patches for Source Parts Inc. PopStick is attached, although marked DO NOT MERGE because the DT should come from Linux after it's ready. To keep thr code that accesses SPI NAND as simple as possible, it assumes fixed page size, which is also what sunxi BROM does. The SUNIV SPL assumes 0x400 page size, but here to utilize the space better, in the attached example of PopStick, U-Boot main part is assumed to be with 0x800 page size (which is the real situation of the W25N01 flash used by PopStick). Icenowy Zheng (8): sunxi: SPL SPI: extract code for doing SPI transfer sunxi: SPL SPI: add support for read command with 2 byte address sunxi: SPL SPI: allow multiple boot attempt sunxi: SPL SPI: add initial support for booting from SPI NAND sunxi: enable support for SPI NAND booting on SUNIV [DO NOT MERGE] sunxi: sync DT from my tree for PopStick [DO NOT MERGE, DIRTY HACK] sunxi: use UBI for environement storage [DO NOT MERGE] sunxi: add a defconfig for PopStick arch/arm/dts/Makefile| 3 +- arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 16 ++ arch/arm/dts/suniv-f1c100s.dtsi | 26 ++ arch/arm/dts/suniv-f1c200s-popstick-v1.1.dts | 101 arch/arm/mach-sunxi/Kconfig | 16 ++ arch/arm/mach-sunxi/board.c | 4 +- arch/arm/mach-sunxi/spl_spi_sunxi.c | 247 ++- board/sunxi/board.c | 1 + configs/popstick_defconfig | 35 +++ 9 files changed, 377 insertions(+), 72 deletions(-) create mode 100644 arch/arm/dts/suniv-f1c200s-popstick-v1.1.dts create mode 100644 configs/popstick_defconfig -- 2.37.1 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20221014030520.3067228-1-uwu%40icenowy.me.
[linux-sunxi] [PATCH 1/8] sunxi: SPL SPI: extract code for doing SPI transfer
To support SPI NAND flashes, more commands than Read (03h) are needed.
Extract the code for doing SPI transfer from the reading code for code
reuse.
Signed-off-by: Icenowy Zheng
---
arch/arm/mach-sunxi/spl_spi_sunxi.c | 105
1 file changed, 59 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c
b/arch/arm/mach-sunxi/spl_spi_sunxi.c
index 925bf85f2d..7975457758 100644
--- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
+++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
@@ -243,77 +243,90 @@ static void spi0_deinit(void)
#define SPI_READ_MAX_SIZE 60 /* FIFO size, minus 4 bytes of the header */
-static void sunxi_spi0_read_data(u8 *buf, u32 addr, u32 bufsize,
-ulong spi_ctl_reg,
-ulong spi_ctl_xch_bitmask,
-ulong spi_fifo_reg,
-ulong spi_tx_reg,
-ulong spi_rx_reg,
-ulong spi_bc_reg,
-ulong spi_tc_reg,
-ulong spi_bcc_reg)
+static void sunxi_spi0_xfer(const u8 *txbuf, u32 txlen,
+ u8 *rxbuf, u32 rxlen,
+ ulong spi_ctl_reg,
+ ulong spi_ctl_xch_bitmask,
+ ulong spi_fifo_reg,
+ ulong spi_tx_reg,
+ ulong spi_rx_reg,
+ ulong spi_bc_reg,
+ ulong spi_tc_reg,
+ ulong spi_bcc_reg)
{
- writel(4 + bufsize, spi_bc_reg); /* Burst counter (total bytes) */
- writel(4, spi_tc_reg); /* Transfer counter (bytes to send) */
+ writel(txlen + rxlen, spi_bc_reg); /* Burst counter (total bytes) */
+ writel(txlen, spi_tc_reg); /* Transfer counter (bytes to send)
*/
if (spi_bcc_reg)
- writel(4, spi_bcc_reg); /* SUN6I also needs this */
+ writel(txlen, spi_bcc_reg); /* SUN6I also needs this */
- /* Send the Read Data Bytes (03h) command header */
- writeb(0x03, spi_tx_reg);
- writeb((u8)(addr >> 16), spi_tx_reg);
- writeb((u8)(addr >> 8), spi_tx_reg);
- writeb((u8)(addr), spi_tx_reg);
+ for (u32 i = 0; i < txlen; i++)
+ writeb(*(txbuf++), spi_tx_reg);
/* Start the data transfer */
setbits_le32(spi_ctl_reg, spi_ctl_xch_bitmask);
/* Wait until everything is received in the RX FIFO */
- while ((readl(spi_fifo_reg) & 0x7F) < 4 + bufsize)
+ while ((readl(spi_fifo_reg) & 0x7F) < txlen + rxlen)
;
- /* Skip 4 bytes */
- readl(spi_rx_reg);
+ /* Skip txlen bytes */
+ for (u32 i = 0; i < txlen; i++)
+ readb(spi_rx_reg);
/* Read the data */
- while (bufsize-- > 0)
- *buf++ = readb(spi_rx_reg);
+ while (rxlen-- > 0)
+ *rxbuf++ = readb(spi_rx_reg);
+}
+
+static void spi0_xfer(const u8 *txbuf, u32 txlen, u8 *rxbuf, u32 rxlen)
+{
+ uintptr_t base = spi0_base_address();
- /* tSHSL time is up to 100 ns in various SPI flash datasheets */
- udelay(1);
+ if (is_sun6i_gen_spi()) {
+ sunxi_spi0_xfer(txbuf, txlen, rxbuf, rxlen,
+ base + SUN6I_SPI0_TCR,
+ SUN6I_TCR_XCH,
+ base + SUN6I_SPI0_FIFO_STA,
+ base + SUN6I_SPI0_TXD,
+ base + SUN6I_SPI0_RXD,
+ base + SUN6I_SPI0_MBC,
+ base + SUN6I_SPI0_MTC,
+ base + SUN6I_SPI0_BCC);
+ } else {
+ sunxi_spi0_xfer(txbuf, txlen, rxbuf, rxlen,
+ base + SUN4I_SPI0_CTL,
+ SUN4I_CTL_XCH,
+ base + SUN4I_SPI0_FIFO_STA,
+ base + SUN4I_SPI0_TX,
+ base + SUN4I_SPI0_RX,
+ base + SUN4I_SPI0_BC,
+ base + SUN4I_SPI0_TC,
+ 0);
+ }
}
static void spi0_read_data(void *buf, u32 addr, u32 len)
{
u8 *buf8 = buf;
u32 chunk_len;
- uintptr_t base = spi0_base_address();
+ u8 txbuf[4];
while (len > 0) {
chunk_len = len;
+
+ /* Configure the Read Data Bytes (03h) command header */
+ txbuf[0] = 0x03;
+ txbuf[1] = (u8)(addr >> 16);
+ txbuf[2] = (u8)(addr >> 8);
+ txbuf[3] = (u8)(addr);
+
if (chunk_len > SPI_READ_MAX_SIZE)
chunk_len = SPI_READ_MAX_SIZE;
- if (is_sun6i_gen_sp
[linux-sunxi] [PATCH 2/8] sunxi: SPL SPI: add support for read command with 2 byte address
This kind of read command is utilized in SPI NANDs for reading data
inside a selected page, which is obviously smaller than how much 2
byte address can address. So 2 bytes are used for the address and one
dummy byte is needed after the real address. As the address is sent out
in bit endian, this makes it not compatible with usual 3 byte address.
Signed-off-by: Icenowy Zheng
---
arch/arm/mach-sunxi/spl_spi_sunxi.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c
b/arch/arm/mach-sunxi/spl_spi_sunxi.c
index 7975457758..88c15a3ee9 100644
--- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
+++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
@@ -305,7 +305,7 @@ static void spi0_xfer(const u8 *txbuf, u32 txlen, u8
*rxbuf, u32 rxlen)
}
}
-static void spi0_read_data(void *buf, u32 addr, u32 len)
+static void spi0_read_data(void *buf, u32 addr, u32 len, u32 addr_len)
{
u8 *buf8 = buf;
u32 chunk_len;
@@ -316,9 +316,15 @@ static void spi0_read_data(void *buf, u32 addr, u32 len)
/* Configure the Read Data Bytes (03h) command header */
txbuf[0] = 0x03;
- txbuf[1] = (u8)(addr >> 16);
- txbuf[2] = (u8)(addr >> 8);
- txbuf[3] = (u8)(addr);
+ if (addr_len == 3) {
+ txbuf[1] = (u8)(addr >> 16);
+ txbuf[2] = (u8)(addr >> 8);
+ txbuf[3] = (u8)(addr);
+ } else if (addr_len == 2) {
+ txbuf[1] = (u8)(addr >> 8);
+ txbuf[2] = (u8)(addr);
+ txbuf[3] = 0; /* dummy */
+ }
if (chunk_len > SPI_READ_MAX_SIZE)
chunk_len = SPI_READ_MAX_SIZE;
@@ -337,7 +343,7 @@ static void spi0_read_data(void *buf, u32 addr, u32 len)
static ulong spi_load_read(struct spl_load_info *load, ulong sector,
ulong count, void *buf)
{
- spi0_read_data(buf, sector, count);
+ spi0_read_data(buf, sector, count, 3);
return count;
}
@@ -356,7 +362,7 @@ static int spl_spi_load_image(struct spl_image_info
*spl_image,
spi0_init();
- spi0_read_data((void *)header, load_offset, 0x40);
+ spi0_read_data((void *)header, load_offset, 0x40, 3);
if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
image_get_magic(header) == FDT_MAGIC) {
@@ -376,7 +382,7 @@ static int spl_spi_load_image(struct spl_image_info
*spl_image,
return ret;
spi0_read_data((void *)spl_image->load_addr,
- load_offset, spl_image->size);
+ load_offset, spl_image->size, 3);
}
spi0_deinit();
--
2.37.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20221014030520.3067228-3-uwu%40icenowy.me.
[linux-sunxi] [PATCH 3/8] sunxi: SPL SPI: allow multiple boot attempt
As we're going to add support for SPI NAND to this code, add code that
allows multiple boot attempts with different load offsets and functions.
To keep compatibility with loading raw binary on SPI NOR, a bool
parameter is used to allow booting without valid magic number when
booting with SPI NOR.
Signed-off-by: Icenowy Zheng
---
arch/arm/mach-sunxi/spl_spi_sunxi.c | 58 +++--
1 file changed, 38 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c
b/arch/arm/mach-sunxi/spl_spi_sunxi.c
index 88c15a3ee9..21be33a23f 100644
--- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
+++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
@@ -340,8 +340,8 @@ static void spi0_read_data(void *buf, u32 addr, u32 len,
u32 addr_len)
}
}
-static ulong spi_load_read(struct spl_load_info *load, ulong sector,
- ulong count, void *buf)
+static ulong spi_load_read_nor(struct spl_load_info *load, ulong sector,
+ ulong count, void *buf)
{
spi0_read_data(buf, sector, count, 3);
@@ -350,41 +350,59 @@ static ulong spi_load_read(struct spl_load_info *load,
ulong sector,
/*/
-static int spl_spi_load_image(struct spl_image_info *spl_image,
- struct spl_boot_device *bootdev)
+static int spl_spi_try_load(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev,
+ struct spl_load_info *load, u32 offset,
+ bool allow_raw)
{
int ret = 0;
struct legacy_img_hdr *header;
- uint32_t load_offset = sunxi_get_spl_size();
-
header = (struct legacy_img_hdr *)CONFIG_SYS_TEXT_BASE;
- load_offset = max_t(uint32_t, load_offset, CONFIG_SYS_SPI_U_BOOT_OFFS);
-
- spi0_init();
- spi0_read_data((void *)header, load_offset, 0x40, 3);
+ if (load->read(load, offset, 0x40, (void *)header) == 0)
+ return -EINVAL;
if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
image_get_magic(header) == FDT_MAGIC) {
- struct spl_load_info load;
debug("Found FIT image\n");
- load.dev = NULL;
- load.priv = NULL;
- load.filename = NULL;
- load.bl_len = 1;
- load.read = spi_load_read;
- ret = spl_load_simple_fit(spl_image, &load,
- load_offset, header);
+ ret = spl_load_simple_fit(spl_image, load,
+ offset, header);
} else {
+ if (!allow_raw && image_get_magic(header) != IH_MAGIC)
+ return -EINVAL;
+
ret = spl_parse_image_header(spl_image, bootdev, header);
if (ret)
return ret;
- spi0_read_data((void *)spl_image->load_addr,
- load_offset, spl_image->size, 3);
+ if (load->read(load, offset, spl_image->size,
+ (void *)spl_image->load_addr) == 0)
+ ret = -EINVAL;
}
+ return ret;
+}
+
+static int spl_spi_load_image(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev)
+{
+ int ret = 0;
+ uint32_t load_offset = sunxi_get_spl_size();
+ struct spl_load_info load;
+
+ load_offset = max_t(uint32_t, load_offset, CONFIG_SYS_SPI_U_BOOT_OFFS);
+
+ load.dev = NULL;
+ load.priv = NULL;
+ load.filename = NULL;
+ load.bl_len = 1;
+
+ spi0_init();
+
+ load.read = spi_load_read_nor;
+ ret = spl_spi_try_load(spl_image, bootdev, &load, load_offset, true);
+
spi0_deinit();
return ret;
--
2.37.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20221014030520.3067228-4-uwu%40icenowy.me.
[linux-sunxi] [PATCH 4/8] sunxi: SPL SPI: add initial support for booting from SPI NAND
This commit adds support for booting from SPI NAND to SPL SPI code by
mimicing the behavior of boot ROM (use fixed page size and sequentially
try SPI NOR and NAND).
Signed-off-by: Icenowy Zheng
---
arch/arm/mach-sunxi/Kconfig | 16 +++
arch/arm/mach-sunxi/spl_spi_sunxi.c | 74 +
2 files changed, 90 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 840bbc19b3..6afbb4acb5 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1018,6 +1018,22 @@ config SPL_SPI_SUNXI
sunxi SPI Flash. It uses the same method as the boot ROM, so does
not need any extra configuration.
+config SPL_SPI_SUNXI_NAND
+ bool "Support for SPI NAND Flash on Allwinner SoCs in SPL"
+ depends on SPL_SPI_SUNXI
+ help
+ Enable support for SPI NAND Flash. This option allows SPL to mimic
+ Allwinner boot ROM's behavior to gain support for SPI NAND Flash;
+ a fixed page size needs to be assumed when building the SPL image.
+
+config SPL_SPI_SUNXI_NAND_ASSUMED_PAGESIZE
+ hex "Assumed pagesize for SPI NAND Flash in SPL"
+ depends on SPL_SPI_SUNXI_NAND
+ default 0x400 if MACH_SUNIV
+ help
+ Set the page size assumed by the SPL SPI NAND code, the default
+ value is the same with the boot ROM.
+
config PINE64_DT_SELECTION
bool "Enable Pine64 device tree selection code"
depends on MACH_SUN50I
diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c
b/arch/arm/mach-sunxi/spl_spi_sunxi.c
index 21be33a23f..5178908327 100644
--- a/arch/arm/mach-sunxi/spl_spi_sunxi.c
+++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c
@@ -305,6 +305,49 @@ static void spi0_xfer(const u8 *txbuf, u32 txlen, u8
*rxbuf, u32 rxlen)
}
}
+#if defined(CONFIG_SPL_SPI_SUNXI_NAND)
+static int spi0_nand_switch_page(u32 page)
+{
+ unsigned count;
+ u8 buf[4];
+
+ /* Configure the Page Data Read (13h) command header */
+ buf[0] = 0x13;
+ buf[1] = (u8)(page >> 16);
+ buf[2] = (u8)(page >> 8);
+ buf[3] = (u8)(page);
+
+ spi0_xfer(buf, 4, NULL, 0);
+
+ /* Wait for NAND chip to exit busy state */
+ buf[0] = 0x0f;
+ buf[1] = 0xc0;
+
+ /* Load a NAND page can take up to 2-decimal-digit microseconds */
+ for (count = 0; count < 100; count ++) {
+ udelay(1);
+ spi0_xfer(buf, 2, buf+2, 1);
+ if (!(buf[2] & 0x1))
+ return 0;
+ }
+
+ return -ETIMEDOUT;
+}
+
+static void spi0_nand_reset(void)
+{
+ u8 buf[1];
+
+ /* Configure the Device RESET (ffh) command */
+ buf[0] = 0xff;
+
+ spi0_xfer(buf, 1, NULL, 0);
+
+ /* Wait for the NAND to finish resetting */
+ udelay(10);
+}
+#endif
+
static void spi0_read_data(void *buf, u32 addr, u32 len, u32 addr_len)
{
u8 *buf8 = buf;
@@ -348,6 +391,28 @@ static ulong spi_load_read_nor(struct spl_load_info *load,
ulong sector,
return count;
}
+#if defined(CONFIG_SPL_SPI_SUNXI_NAND)
+static ulong spi_load_read_nand(struct spl_load_info *load, ulong sector,
+ ulong count, void *buf)
+{
+ const ulong pagesize = CONFIG_SPL_SPI_SUNXI_NAND_ASSUMED_PAGESIZE;
+ ulong remain = count;
+
+ while (remain) {
+ ulong count_in_page = min(remain, pagesize - (sector %
pagesize));
+ ulong current_page = sector / pagesize;
+ if (spi0_nand_switch_page(current_page) != 0)
+ return 0;
+ spi0_read_data(buf, sector % pagesize, count_in_page, 2);
+ remain -= count_in_page;
+ sector += count_in_page;
+ buf += count_in_page;
+ }
+
+ return count;
+}
+#endif
+
/*/
static int spl_spi_try_load(struct spl_image_info *spl_image,
@@ -400,9 +465,18 @@ static int spl_spi_load_image(struct spl_image_info
*spl_image,
spi0_init();
+#if defined(CONFIG_SPL_SPI_SUNXI_NAND)
+ spi0_nand_reset();
+ load.read = spi_load_read_nand;
+ ret = spl_spi_try_load(spl_image, bootdev, &load, load_offset, false);
+ if (!ret)
+ goto out;
+#endif
+
load.read = spi_load_read_nor;
ret = spl_spi_try_load(spl_image, bootdev, &load, load_offset, true);
+out:
spi0_deinit();
return ret;
--
2.37.1
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20221014030520.3067228-5-uwu%40icenowy.me.
Re: [linux-sunxi] Re: [PATCH 52/54] arm64: dts: allwinner: Remove regulator-ramp-delay
于 2021年8月6日 GMT+08:00 下午8:05:56, Chen-Yu Tsai 写到: >On Fri, Aug 6, 2021 at 7:49 PM Icenowy Zheng wrote: >> >> 在 2021-07-22星期四的 10:16 +0200，Maxime Ripard写道： >> > On Thu, Jul 22, 2021 at 12:55:53AM -0500, Samuel Holland wrote: >> > > On 7/21/21 9:04 AM, Maxime Ripard wrote: >> > > > The regulator-ramp-delay property isn't documented in the binding >> > > > for >> > > > the AXP806, and it's ignored by the driver. Remove those >> > > > properties. >> > > >> > > This is a generic regulator property, parsed by >> > > of_get_regulation_constraints, which is called by >> > > regulator_of_get_init_data in the regulator core. And it appears in >> > > bindings/regulator/regulator.yaml. I believe the binding needs to be >> > > fixed, not the device trees. >> > >> > It's indeed parsed by the regulator framework, but then it calls into >> > the driver if that property is set using set_ramp_delay if it's set. >> >> Not only is it used for set_ramp_delay, but it's also used to calculate >> a post-change delay, see the following position (it can be overrided by >> a custom set_voltage_time in the driver): >> >> https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L3339 > >Having just dug through the regulator core code at work, I agree. > >Furthermore, the commit log for this addition specifically mentions the >reason for adding this property is to provide a (guessed) ramp rate for >the core to do a proper delay for the regulator to ramp up, not to set >the actual ramp rate in hardware. Well we must agree that we have some more suitable property that delays for a constant span, see lines below in the function I mentioned. > > >ChenYu > > >[1] https://git.kernel.org/torvalds/c/fe79ea577be81e1e71642826ab00e676dc59c194 > >> > >> > https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L1378 >> > >> > We don't set that hook for the AXP806 DCDC-A and DCDC-E regulators >> > (that >> > use AXP_DESC_RANGES) at all: >> > >> > https://elixir.bootlin.com/linux/latest/source/drivers/regulator/axp20x-regulator.c#L343 >> > >> > And the only implementation we have (set for AXP_DESC and AXP_DESC_IO) >> > works only for the AXP209: >> > >> > https://elixir.bootlin.com/linux/latest/source/drivers/regulator/axp20x-regulator.c#L368 >> > >> > So, it just looks like those properties have never been tested since >> > they were just ignored. >> > >> > Maxime >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "linux-sunxi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to linux-sunxi+unsubscr...@googlegroups.com. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/linux-sunxi/68e4820ead3107aa4e80dcaf9243bd11de5fce98.camel%40aosc.io. > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/0308F3FA-B5DE-4FFC-AD22-4F5E94CDF466%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 52/54] arm64: dts: allwinner: Remove regulator-ramp-delay
在 2021-07-22星期四的 10:16 +0200，Maxime Ripard写道： > On Thu, Jul 22, 2021 at 12:55:53AM -0500, Samuel Holland wrote: > > On 7/21/21 9:04 AM, Maxime Ripard wrote: > > > The regulator-ramp-delay property isn't documented in the binding > > > for > > > the AXP806, and it's ignored by the driver. Remove those > > > properties. > > > > This is a generic regulator property, parsed by > > of_get_regulation_constraints, which is called by > > regulator_of_get_init_data in the regulator core. And it appears in > > bindings/regulator/regulator.yaml. I believe the binding needs to be > > fixed, not the device trees. > > It's indeed parsed by the regulator framework, but then it calls into > the driver if that property is set using set_ramp_delay if it's set. Not only is it used for set_ramp_delay, but it's also used to calculate a post-change delay, see the following position (it can be overrided by a custom set_voltage_time in the driver): https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L3339 > > https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L1378 > > We don't set that hook for the AXP806 DCDC-A and DCDC-E regulators > (that > use AXP_DESC_RANGES) at all: > > https://elixir.bootlin.com/linux/latest/source/drivers/regulator/axp20x-regulator.c#L343 > > And the only implementation we have (set for AXP_DESC and AXP_DESC_IO) > works only for the AXP209: > > https://elixir.bootlin.com/linux/latest/source/drivers/regulator/axp20x-regulator.c#L368 > > So, it just looks like those properties have never been tested since > they were just ignored. > > Maxime > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/68e4820ead3107aa4e80dcaf9243bd11de5fce98.camel%40aosc.io.
[linux-sunxi] Re: [PATCH v7 06/19] rtc: sun6i: Add support for RTCs without external LOSCs
于 2021年7月29日 GMT+08:00 下午6:32:28, Maxime Ripard 写到: >On Thu, Jul 29, 2021 at 04:04:10PM +0800, Icenowy Zheng wrote: >> 在 2021-06-16星期三的 11:14 +0200，Maxime Ripard写道： >> > Hi, >> > >> > On Tue, Jun 15, 2021 at 12:06:23PM +0100, Andre Przywara wrote: >> > > Some newer Allwinner RTCs (for instance the one in the H616 SoC) >> > > lack >> > > a pin for an external 32768 Hz oscillator. As a consequence, this >> > > LOSC >> > > can't be selected as the RTC clock source, and we must rely on the >> > > internal RC oscillator. >> > > To allow additions of clocks to the RTC node, add a feature bit to >> > > ignore >> > > any provided clocks for now (the current code would think this is >> > > the >> > > external LOSC). Later DTs and code can then for instance add the >> > > PLL >> > > based clock input, and older kernel won't get confused. >> > > >> > > Signed-off-by: Andre Przywara >> > >> > Honestly, I don't really know if it's worth it at this point. >> > >> > If we sums this up: >> > >> > - The RTC has 2 features that we use, mostly centered around 2 >> > registers set plus a global one >> > >> > - Those 2 features are programmed in a completely different way >> > >> > - Even the common part is different, given the discussion around the >> > clocks that we have. >> > >> > What is there to share in that driver aside from the probe, and maybe >> > the interrupt handling? Instead of complicating this further with >> > more >> > special case that you were (rightfully) complaining about, shouldn't >> > we >> > just acknowledge the fact that it's a completely separate design and >> > should be treated as such, with a completely separate driver? >> >> I think our problem is just that we're having a single driver for both >> functionalities (clock manager and RTC). >> >> Personally I don't think we should have seperated driver for clock >> managers, although I am fine with seperated RTC driver for linear days. > >Why do you think it's a bad idea to have the RTC and clocks in the same >driver? Well you really misread, I'm just thinking we shouldn't have a new driver from scratch. As we're going to have a single sun6i-rtc, please allow H616 and R329 to enter it. > >Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/E4567E12-60C1-4DF5-89D6-C93DC3152D4F%40aosc.io.
[linux-sunxi] Re: [PATCH v7 06/19] rtc: sun6i: Add support for RTCs without external LOSCs
在 2021-06-16星期三的 11:14 +0200，Maxime Ripard写道： > Hi, > > On Tue, Jun 15, 2021 at 12:06:23PM +0100, Andre Przywara wrote: > > Some newer Allwinner RTCs (for instance the one in the H616 SoC) > > lack > > a pin for an external 32768 Hz oscillator. As a consequence, this > > LOSC > > can't be selected as the RTC clock source, and we must rely on the > > internal RC oscillator. > > To allow additions of clocks to the RTC node, add a feature bit to > > ignore > > any provided clocks for now (the current code would think this is > > the > > external LOSC). Later DTs and code can then for instance add the > > PLL > > based clock input, and older kernel won't get confused. > > > > Signed-off-by: Andre Przywara > > Honestly, I don't really know if it's worth it at this point. > > If we sums this up: > > - The RTC has 2 features that we use, mostly centered around 2 > registers set plus a global one > > - Those 2 features are programmed in a completely different way > > - Even the common part is different, given the discussion around the > clocks that we have. > > What is there to share in that driver aside from the probe, and maybe > the interrupt handling? Instead of complicating this further with > more > special case that you were (rightfully) complaining about, shouldn't > we > just acknowledge the fact that it's a completely separate design and > should be treated as such, with a completely separate driver? I think our problem is just that we're having a single driver for both functionalities (clock manager and RTC). Personally I don't think we should have seperated driver for clock managers, although I am fine with seperated RTC driver for linear days. By the way, not having a LOSC is only what happens on H616, maybe because there should never be a battery-backed H616 device. On R329, the RTC part has linear day storage, but it still have LOSC. Because of this, I don't think we should duplicate at least at least the current sun6i-rtc dual-functionality driver, because the clock funtionality is just the same with previous SoCs on R329. > > Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/1e49692a2f4548ae942e170bc1ae9431a6eb512e.camel%40aosc.io.
[linux-sunxi] Re: [PATCH v8 00/11] arm64: sunxi: Initial Allwinner H616 SoC support
在 2021-07-23星期五的 16:38 +0100，Andre Przywara写道： > Hi, > > another try on the basic Allwinner H616 support, now on top of 5.14- > rc1. > > This time I dropped the USB support from the basic series, to split > off > the discussion, and simplify the core SoC support. I will post the > USB > series soon, to be applied on top. > I kept the RTC support in, even though this is still under > discussion, > because this is important to keep future DT files compatible with > this > kernel. This gains one fix patch for the existing RTC driver. Well, I think RTC is really a fundmental part of SoC support now. I think if I post my R329 patchset, it will depend on this patchset's RTC part (R329 has linear day too, although it still has external LOSC (and even LOSC fanout) ). BTW Thanks for your code ;-) > > For a complete changelog, see below. > > Based on 5.14-rc1. Let me know if you need a different base. > Relies on this pinctrl fix: > http://lists.infradead.org/pipermail/linux-arm-kernel/2021-July/672813.html > > Also available here: > https://github.com/apritzel/linux/commits/h616-v8 > > Thanks! > Andre > > == > This series gathers patches to support the Allwinner H616 SoC. This > is > a rather uninspired SoC (Quad-A53 with the usual peripherals), but > allows for some cheap development boards and TV boxes, and supports > up to 4GB of DRAM. > > Some DT binding patches are sprinkled throughout the series, to add > the new compatible names right before they are used. > Patch 3-7 add support for the new RTC: the date is now stored as a > linear number, not broken down into day-month-year. The benefit is > that > this lifts the limit of the old date counter, which would have rolled > over around 2032. Also the alarm setting is using the same storage > format as the current time, compared to the number of seconds left > used > in existing SoCs. > Eventually we get the .dtsi for the SoC in patch 8, and the .dts for > the OrangePi Zero2 board[1] in the penultimate patch, followed by > the .dts for the X96 Mate TV box[2] in the final commit. > > U-Boot and Trusted Firmware support is now merged in released > versions, > it allows booting via FEL or SD card, also you can TFTP kernels in on > the OrangePi Zero 2 board. > > Many thanks to Jernej for his tremendous help on this, also for the > awesome input and help from the #linux-sunxi Freenode channel. > > The whole series (including the pinctrl fix) can also be found here: > https://github.com/apritzel/linux/commits/h616-v8 > > Happy reviewing! > > Cheers, > Andre > > [1] https://linux-sunxi.org/Orange_Pi_Zero_2 > [2] https://linux-sunxi.org/X96_Mate > > Changelog v7 .. v8: > - Rebase on top of 5.14-rc1, which already includes the previous v7 > 02/19 > - Drop USB and Ethernet patches (to keep series small) > - Use "clocks: false" in RTC DT binding (2/11) > - Include fix for RTC overflow check (3/11) > - Use div_64() to avoid linking error on some 32-bit platforms > (4+5/11) > - Adjust to changed RTC overflow check (5/11) > - Drop USB nodes from .dtsi file > - Move mmc-ddr-1_8v property from .dtsi file into board .dts > - Fix DTC warnings (underscore in node name, soc@0, #a-c in IRQ > controllers) > > Changelog v6 .. v7: > - Fix AXP305 binding documentation blunder (01/19) > - Improve new linear day support (use existing conversion functions) > (04/19) > - Add support for changed RTC alarm registers (05/19) > - Add support for RTCs without a LOSC clock (06/19) > - Rework USB PHY2 SIDDQ quirk to use PHY clocks directly (14/19) > - Add X96 Mate compatible string to binding doc (17/19) > - Add Rob's ACKs > > Changelog v5 .. v6: > - Drop already merged clock, pinctrl and MMC support from this series > - Properly fix AXP support by skipping power key initialisation > - Add patch to support new RTC date storage encoding > - Re-add USB HCI PHY refactoring > - Add patch to allow USB reset line sharing > - Add patch to introduce quirk for PHY2 SIDDQ clearing > - Re-add USB nodes to the .dtsi > - Add USB gadget support > - Add DT for X96 Mate TV box > > Changelog v4 .. v5: > - Fix CCU binding to pass dtbs_check > - Add RSB compatible string to binding doc > - Rename IR pin name to pass dtbs_check > - Add EMAC compatible string to binding doc > - Drop USB PHY support and binding doc patches > - Drop USB nodes from .dtsi and .dts > - Drop second EMAC node from .dtsi > > Changelog v3 .. v4: > - Drop MMC and pinctrl matches (already in some -next trees) > - Add Maxime's Acks > - Add patch to update the AXP MFD DT bindings > - Add new patch (05/21) to fix axp20x-pek driver > - Change AXP IRQ fix to check for invalid IRQ line number > - Split joint DT bindings patch (v3 18/21) into subsystems > - move dwmac variable to keep christmas tree > - Use enums for USB PHY compatible strings in DT binding > - Enable watchdog (briefly verified to work) > - Add PHY2 to HCI1&3, this fixes USB > - limit r-ccu register frame length to not collide with NMI > control
[linux-sunxi] Re: [PATCH v3 0/6] PWM support for allwinner sun8i R40/T3/V40 SOCs.
Hao, Would you mind me to continue on this work? Newer Allwinner SoCs have PWM controllers similar to the R40 one. Yours sincerely, Icenowy Zheng 在 2018-11-26星期一的 00:18 +0800，Hao Zhang写道： > PWM support for allwinner sun8i R40/T3/V40 SOCs. > > The sun8i R40/T3/V40 PWM has 8 PWM channals and divides to 4 PWM > pairs, > each PWM pair built-in 1 clock module, 2 timer logic module and 1 > programmable dead-time generator, it also support waveform capture. > It has 2 clock sources OSC24M and APB1, it is different with the > sun4i-pwm driver, Therefore add a new driver for it. > > Some test method: > cd /sys/class/pwm/pwmchip0 > echo 0 > export > cd pwm0 > echo 1000 > period > echo 500 > duty_cycle > echo 1 > enable > then check the PB2 pin with oscilloscope. > > v3 Changes: > 1. fix coding format. > 2. use 2/ilog2 instead of divide table > 3. remove spinlock. > 4. remove sun8i_pwm_data structure and use DT to parse pwm-channals > 5. remove inline because complier knows it better. > 6. don't hardcode clock source and parse two clock source from dt > "mux-0" > and "mux-1" > 7. remove bypass method. > 8. add a method to change clock source when mux-0 is not support the > input period it can change to mux-1. > 9. add cycle range check. > 10. add some variable to make it more readability. > 11. add clk_disable_unprepare when some false accur. > > v2 Changes: > 1. change sun8i-r40 symbol to sun8i. > 2. change pwm0_pin, pwm0-pin to pwm_ch0_pin, pwm-ch0-pin. > 3. remove clk_disable_unprepare(), check !match and IS_ERR(pwm- > >regmap). > > Hao Zhang (6): > Documentation: ARM: sunxi: pwm: add Allwinner sun8i. > ARM: dtsi: add pwm node for sun8i R40. > ARM: dts: add PWM for Bananapi M2 Ultrar board. > DEV: CLK: add function to check the using clock name of driver. > DEV: CLK: sunxi ccu: export clk_apb1 for sun8i-r40 soc pwm. > ARM: PWM: add allwinner sun8i R40/T3/V40 PWM support. > > .../devicetree/bindings/pwm/pwm-sun8i.txt | 24 ++ > arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 6 + > arch/arm/boot/dts/sun8i-r40.dtsi | 17 + > drivers/clk/clk.c | 6 + > drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 4 +- > drivers/pwm/Kconfig | 12 +- > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-sun8i.c | 418 > + > include/dt-bindings/clock/sun8i-r40-ccu.h | 2 + > include/linux/clk-provider.h | 1 + > 10 files changed, 489 insertions(+), 2 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pwm/pwm- > sun8i.txt > create mode 100644 drivers/pwm/pwm-sun8i.c > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/0a9bda1e91246c7e473fcbb833ac94159d13b084.camel%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 2/2] sunxi: enable dual rank memory on R40
在 2021-03-02星期二的 15:19 +，Andre Przywara写道： > On Tue, 02 Mar 2021 21:50:49 +0800 > Icenowy Zheng wrote: > > Hi Icenowy, > > > 于 2021年3月2日 GMT+08:00 下午9:40:44, Andre Przywara < > > andre.przyw...@arm.com> 写到: > > > On Fri, 26 Feb 2021 00:13:25 +0800 > > > Icenowy Zheng wrote: > > > > > > > Previously we do not have proper dual rank memory detection on > > > > R40 > > > > (because we omitted PIR_QSGATE, which does not work on R40 with > > > > our > > > > configuration), and dual rank memory is just simply disabled as > > > > early > > > > R40 boards available (Banana Pi M2 Ultra and Berry) have single > > > > rank > > > > memory. > > > > > > > > As a board with dual rank memory (Forlinx OKA40i-C) is now > > > > known to > > > us, > > > > we need to have a way to do memory rank detection to support > > > > that > > > board. > > > > > > > > Add some routine to detect memory rank by trying to access the > > > > memory > > > > in rank 1 and check for error status of the memory controller, > > > > and > > > then > > > > enable dual rank memory on R40. > > > > > > > > Similar routine can be used to detect half DQ width (which is > > > > also > > > > detected by PIR_QSGATE on other SoCs), but it's left > > > > unimplemented > > > > because there's no known R40 board with half DQ width now. > > > > > > So when looking at the SPL size I realised that this patch breaks > > > the > > > socid constant parameter propagation, especially for > > > mctl_set_cr(). I > > > don't see immediately why, this whole code here should be > > > compiled out > > > on any A64 builds, for instance. Instead GCC turns > > > ":" into ":", and passes > > > 0x1689 > > > around everytime. I tried GCC 10.2.0 and 9.2.0, also tried adding > > > const > > > everywhere, to amplify the constant nature of this value. Patch > > > 1/2 added to the code size, but kept the const propagation (only > > > one > > > instance of 0x1689 in the disassembly). This patch here should be > > > for > > > free on A64, but adds 104 bytes. > > > > > > Does anyone have a clue why this is happening? Is this a compiler > > > issue? > > > > Maybe the issue is that I assume this codepath is only for R40 and > > I didn't add socid to it? > > But that's clearly visible by this function only being called inside > "if > (socid == SOCID_R40)". And that works very well for the H3 ZQ > calibration quirk, for instance. > > > Could you try to add a socid parameter to > > mctl_r40_detect_rank_count()? > > I just tried that, and apart from looking weird it didn't do > anything. > > To be clear: Your code is absolutely fine, exactly the way it should > be > written. It's just that the compiler is playing stupid suddenly. I > was > thinking that your dummy readl might have upset it, but even with > that > commented out it's still happening. > > > Or maybe it makes mctl_calc_rank_size() not inlined? > > So the assembly looks like everything apart from mctl_set_cr() and > mctl_auto_detect_dram_size_rank() is inlined. Those are extra because > they are called multiple times and we are using -Os. > > > (Well I think the code looks noop on non-R40) > > Exactly that was my thinking: when compiling for the A64, it should > be > totally compiled out, and the object file should be the same before > and > after. > > > BTW, original rank/width detection part won't get called on R40. > > But > > R40 is not where we are tight on code size, so I didn't bother to > > ignore > > it on R40. > > I see. Yeah, I am not concerned about R40 either, but I want to avoid > the A64 bloating up. > > > Or should we switch back to #if's and do not rely on compiler > > behavior any longer? > > I'd rather not do that. We are doing the right thing, and it works > marvellously so far. > > To be clear: it's not a show stopper, I was just curious why this > happens. > The code size is not really critical on the A64 at the moment, so I'd > merge it as it, even if we don't find a solution. Maybe just leave a > hint about it in the code should people need to come back to this. > &g
Re: [linux-sunxi] Re: [PATCH 2/2] sunxi: enable dual rank memory on R40
在 2021-03-02星期二的 15:19 +，Andre Przywara写道： > On Tue, 02 Mar 2021 21:50:49 +0800 > Icenowy Zheng wrote: > > Hi Icenowy, > > > 于 2021年3月2日 GMT+08:00 下午9:40:44, Andre Przywara < > > andre.przyw...@arm.com> 写到: > > > On Fri, 26 Feb 2021 00:13:25 +0800 > > > Icenowy Zheng wrote: > > > > > > > Previously we do not have proper dual rank memory detection on > > > > R40 > > > > (because we omitted PIR_QSGATE, which does not work on R40 with > > > > our > > > > configuration), and dual rank memory is just simply disabled as > > > > early > > > > R40 boards available (Banana Pi M2 Ultra and Berry) have single > > > > rank > > > > memory. > > > > > > > > As a board with dual rank memory (Forlinx OKA40i-C) is now > > > > known to > > > us, > > > > we need to have a way to do memory rank detection to support > > > > that > > > board. > > > > > > > > Add some routine to detect memory rank by trying to access the > > > > memory > > > > in rank 1 and check for error status of the memory controller, > > > > and > > > then > > > > enable dual rank memory on R40. > > > > > > > > Similar routine can be used to detect half DQ width (which is > > > > also > > > > detected by PIR_QSGATE on other SoCs), but it's left > > > > unimplemented > > > > because there's no known R40 board with half DQ width now. > > > > > > So when looking at the SPL size I realised that this patch breaks > > > the > > > socid constant parameter propagation, especially for > > > mctl_set_cr(). I > > > don't see immediately why, this whole code here should be > > > compiled out > > > on any A64 builds, for instance. Instead GCC turns > > > ":" into ":", and passes > > > 0x1689 > > > around everytime. I tried GCC 10.2.0 and 9.2.0, also tried adding > > > const > > > everywhere, to amplify the constant nature of this value. Patch > > > 1/2 added to the code size, but kept the const propagation (only > > > one > > > instance of 0x1689 in the disassembly). This patch here should be > > > for > > > free on A64, but adds 104 bytes. > > > > > > Does anyone have a clue why this is happening? Is this a compiler > > > issue? > > > > Maybe the issue is that I assume this codepath is only for R40 and > > I didn't add socid to it? > > But that's clearly visible by this function only being called inside > "if > (socid == SOCID_R40)". And that works very well for the H3 ZQ > calibration quirk, for instance. > > > Could you try to add a socid parameter to > > mctl_r40_detect_rank_count()? > > I just tried that, and apart from looking weird it didn't do > anything. > > To be clear: Your code is absolutely fine, exactly the way it should > be > written. It's just that the compiler is playing stupid suddenly. I > was > thinking that your dummy readl might have upset it, but even with > that > commented out it's still happening. > > > Or maybe it makes mctl_calc_rank_size() not inlined? > > So the assembly looks like everything apart from mctl_set_cr() and > mctl_auto_detect_dram_size_rank() is inlined. Those are extra because > they are called multiple times and we are using -Os. > > > (Well I think the code looks noop on non-R40) > > Exactly that was my thinking: when compiling for the A64, it should > be > totally compiled out, and the object file should be the same before > and > after. > > > BTW, original rank/width detection part won't get called on R40. > > But > > R40 is not where we are tight on code size, so I didn't bother to > > ignore > > it on R40. > > I see. Yeah, I am not concerned about R40 either, but I want to avoid > the A64 bloating up. > > > Or should we switch back to #if's and do not rely on compiler > > behavior any longer? > > I'd rather not do that. We are doing the right thing, and it works > marvellously so far. > > To be clear: it's not a show stopper, I was just curious why this > happens. > The code size is not really critical on the A64 at the moment, so I'd > merge it as it, even if we don't find a solution. Maybe just leave a > hint about it in the code should people nee
[linux-sunxi] Re: [PATCH 2/2] sunxi: enable dual rank memory on R40
于 2021年3月2日 GMT+08:00 下午9:40:44, Andre Przywara 写到:
>On Fri, 26 Feb 2021 00:13:25 +0800
>Icenowy Zheng wrote:
>
>> Previously we do not have proper dual rank memory detection on R40
>> (because we omitted PIR_QSGATE, which does not work on R40 with our
>> configuration), and dual rank memory is just simply disabled as early
>> R40 boards available (Banana Pi M2 Ultra and Berry) have single rank
>> memory.
>>
>> As a board with dual rank memory (Forlinx OKA40i-C) is now known to
>us,
>> we need to have a way to do memory rank detection to support that
>board.
>>
>> Add some routine to detect memory rank by trying to access the memory
>> in rank 1 and check for error status of the memory controller, and
>then
>> enable dual rank memory on R40.
>>
>> Similar routine can be used to detect half DQ width (which is also
>> detected by PIR_QSGATE on other SoCs), but it's left unimplemented
>> because there's no known R40 board with half DQ width now.
>
>So when looking at the SPL size I realised that this patch breaks the
>socid constant parameter propagation, especially for mctl_set_cr(). I
>don't see immediately why, this whole code here should be compiled out
>on any A64 builds, for instance. Instead GCC turns
>":" into ":", and passes 0x1689
>around everytime. I tried GCC 10.2.0 and 9.2.0, also tried adding const
>everywhere, to amplify the constant nature of this value. Patch
>1/2 added to the code size, but kept the const propagation (only one
>instance of 0x1689 in the disassembly). This patch here should be for
>free on A64, but adds 104 bytes.
>
>Does anyone have a clue why this is happening? Is this a compiler
>issue?
Maybe the issue is that I assume this codepath is only for R40 and
I didn't add socid to it?
Could you try to add a socid parameter to mctl_r40_detect_rank_count()?
Or maybe it makes mctl_calc_rank_size() not inlined?
(Well I think the code looks noop on non-R40)
BTW, original rank/width detection part won't get called on R40. But
R40 is not where we are tight on code size, so I didn't bother to ignore
it on R40.
Or should we switch back to #if's and do not rely on compiler behavior any
longer?
>
>Cheers,
>Andre
>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm/mach-sunxi/dram_sunxi_dw.c | 55
>+
>> 1 file changed, 49 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> index 2b9d631d49..b86ae7cdf3 100644
>> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
>> @@ -414,11 +414,9 @@ static void mctl_set_cr(uint16_t socid, struct
>dram_para *para)
>> }
>>
>> if (socid == SOCID_R40) {
>> -if (para->dual_rank)
>> -panic("Dual rank memory not supported\n");
>> -
>> /* Mux pin to A15 address line for single rank memory. */
>> -setbits_le32(&mctl_com->cr_r1, MCTL_CR_R1_MUX_A15);
>> +if (!para->dual_rank)
>> +setbits_le32(&mctl_com->cr_r1, MCTL_CR_R1_MUX_A15);
>> }
>> }
>>
>> @@ -702,8 +700,55 @@ static unsigned long mctl_calc_rank_size(struct
>rank_para *rank)
>> return (1UL << (rank->row_bits + rank->bank_bits)) *
>rank->page_size;
>> }
>>
>> +/*
>> + * Because we cannot do mctl_phy_init(PIR_QSGATE) on R40 now (which
>leads
>> + * to failure), it's needed to detect the rank count of R40 in
>another way.
>> + *
>> + * The code here is modelled after time_out_detect() in BSP, which
>tries to
>> + * access the memory and check for error code.
>> + *
>> + * TODO: auto detect half DQ width here
>> + */
>> +static void mctl_r40_detect_rank_count(struct dram_para *para)
>> +{
>> +ulong rank1_base = (ulong) CONFIG_SYS_SDRAM_BASE +
>> + mctl_calc_rank_size(¶->ranks[0]);
>> +struct sunxi_mctl_ctl_reg * const mctl_ctl =
>> +(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>> +
>> +/* Enable read time out */
>> +setbits_le32(&mctl_ctl->pgcr[0], 0x1 << 25);
>> +
>> +(void) readl((void *) rank1_base);
>> +udelay(10);
>> +
>> +if (readl(&mctl_ctl->pgsr[0]) & (0x1 << 13)) {
>> +clrsetbits_le32(&mctl_ctl->dtcr, 0xf << 24, 0x1 << 24);
>> +para->dual_rank = 0;
>> +}
>
[linux-sunxi] [PATCH 2/2] sunxi: enable dual rank memory on R40
Previously we do not have proper dual rank memory detection on R40
(because we omitted PIR_QSGATE, which does not work on R40 with our
configuration), and dual rank memory is just simply disabled as early
R40 boards available (Banana Pi M2 Ultra and Berry) have single rank
memory.
As a board with dual rank memory (Forlinx OKA40i-C) is now known to us,
we need to have a way to do memory rank detection to support that board.
Add some routine to detect memory rank by trying to access the memory
in rank 1 and check for error status of the memory controller, and then
enable dual rank memory on R40.
Similar routine can be used to detect half DQ width (which is also
detected by PIR_QSGATE on other SoCs), but it's left unimplemented
because there's no known R40 board with half DQ width now.
Signed-off-by: Icenowy Zheng
---
arch/arm/mach-sunxi/dram_sunxi_dw.c | 55 +
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
b/arch/arm/mach-sunxi/dram_sunxi_dw.c
index 2b9d631d49..b86ae7cdf3 100644
--- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
+++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
@@ -414,11 +414,9 @@ static void mctl_set_cr(uint16_t socid, struct dram_para
*para)
}
if (socid == SOCID_R40) {
- if (para->dual_rank)
- panic("Dual rank memory not supported\n");
-
/* Mux pin to A15 address line for single rank memory. */
- setbits_le32(&mctl_com->cr_r1, MCTL_CR_R1_MUX_A15);
+ if (!para->dual_rank)
+ setbits_le32(&mctl_com->cr_r1, MCTL_CR_R1_MUX_A15);
}
}
@@ -702,8 +700,55 @@ static unsigned long mctl_calc_rank_size(struct rank_para
*rank)
return (1UL << (rank->row_bits + rank->bank_bits)) * rank->page_size;
}
+/*
+ * Because we cannot do mctl_phy_init(PIR_QSGATE) on R40 now (which leads
+ * to failure), it's needed to detect the rank count of R40 in another way.
+ *
+ * The code here is modelled after time_out_detect() in BSP, which tries to
+ * access the memory and check for error code.
+ *
+ * TODO: auto detect half DQ width here
+ */
+static void mctl_r40_detect_rank_count(struct dram_para *para)
+{
+ ulong rank1_base = (ulong) CONFIG_SYS_SDRAM_BASE +
+ mctl_calc_rank_size(¶->ranks[0]);
+ struct sunxi_mctl_ctl_reg * const mctl_ctl =
+ (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
+
+ /* Enable read time out */
+ setbits_le32(&mctl_ctl->pgcr[0], 0x1 << 25);
+
+ (void) readl((void *) rank1_base);
+ udelay(10);
+
+ if (readl(&mctl_ctl->pgsr[0]) & (0x1 << 13)) {
+ clrsetbits_le32(&mctl_ctl->dtcr, 0xf << 24, 0x1 << 24);
+ para->dual_rank = 0;
+ }
+
+ /* Reset PHY FIFO to clear it */
+ clrbits_le32(&mctl_ctl->pgcr[0], 0x1 << 26);
+ udelay(100);
+ setbits_le32(&mctl_ctl->pgcr[0], 0x1 << 26);
+
+ /* Clear error status */
+ setbits_le32(&mctl_ctl->pgcr[0], 0x1 << 24);
+
+ /* Clear time out flag */
+ clrbits_le32(&mctl_ctl->pgsr[0], 0x1 << 13);
+
+ /* Disable read time out */
+ clrbits_le32(&mctl_ctl->pgcr[0], 0x1 << 25);
+}
+
static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para *para)
{
+ if (socid == SOCID_R40) {
+ mctl_r40_detect_rank_count(para);
+ mctl_set_cr(socid, para);
+ }
+
mctl_auto_detect_dram_size_rank(socid, para,
(ulong)CONFIG_SYS_SDRAM_BASE, ¶->ranks[0]);
if ((socid == SOCID_A64 || socid == SOCID_R40) && para->dual_rank) {
@@ -854,8 +899,6 @@ unsigned long sunxi_dram_init(void)
uint16_t socid = SOCID_H3;
#elif defined(CONFIG_MACH_SUN8I_R40)
uint16_t socid = SOCID_R40;
- /* Currently we cannot support R40 with dual rank memory */
- para.dual_rank = 0;
#elif defined(CONFIG_MACH_SUN8I_V3S)
uint16_t socid = SOCID_V3S;
#elif defined(CONFIG_MACH_SUN50I)
--
2.30.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20210225161325.94019-3-icenowy%40aosc.io.
[linux-sunxi] [PATCH 1/2] sunxi: support asymmetric dual rank DRAM on A64/R40
Previously we have known that R40 has a configuration register for its
rank 1, which allows different configuration than rank 0. Reverse
engineering of newest libdram of A64 from Allwinner shows that A64 has
this register too. It's bit 0 (which enables dual rank in rank 0
configuration register) means a dedicated rank size setup is used for
rank 1.
Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
DRAM support necessary.
Add this support. The code could support both A64 and R40, but because
dual rank detection is broken on R40 now, we cannot really use it on R40
currently.
Signed-off-by: Icenowy Zheng
---
.../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 ++-
arch/arm/mach-sunxi/dram_sunxi_dw.c | 94 +++
2 files changed, 82 insertions(+), 23 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
index a5a7ebde44..e843c14202 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
@@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
#define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
/* The eight data lines (DQn) plus DM, DQS and DQSN */
#define LINES_PER_BYTE_LANE(BITS_PER_BYTE + 3)
-struct dram_para {
+
+struct rank_para {
u16 page_size;
- u8 bus_full_width;
- u8 dual_rank;
u8 row_bits;
u8 bank_bits;
+};
+
+struct dram_para {
+ u8 dual_rank;
+ u8 bus_full_width;
+ struct rank_para ranks[2];
const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
const u8 ac_delays[31];
diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
b/arch/arm/mach-sunxi/dram_sunxi_dw.c
index d0600011ff..2b9d631d49 100644
--- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
+++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
@@ -399,11 +399,19 @@ static void mctl_set_cr(uint16_t socid, struct dram_para
*para)
#else
#error Unsupported DRAM type!
#endif
- (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
MCTL_CR_FOUR_BANKS) |
+ (para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
MCTL_CR_FOUR_BANKS) |
MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
(para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
- MCTL_CR_PAGE_SIZE(para->page_size) |
- MCTL_CR_ROW_BITS(para->row_bits), &mctl_com->cr);
+ MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
+ MCTL_CR_ROW_BITS(para->ranks[0].row_bits), &mctl_com->cr);
+
+ if (para->dual_rank && (socid == SOCID_A64 || socid == SOCID_R40)) {
+ writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
MCTL_CR_FOUR_BANKS) |
+ MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
+ MCTL_CR_DUAL_RANK |
+ MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
+ MCTL_CR_ROW_BITS(para->ranks[1].row_bits),
&mctl_com->cr_r1);
+ }
if (socid == SOCID_R40) {
if (para->dual_rank)
@@ -646,35 +654,63 @@ static int mctl_channel_init(uint16_t socid, struct
dram_para *para)
return 0;
}
-static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para *para)
+/*
+ * Test if memory at offset offset matches memory at a certain base
+ */
+static bool mctl_mem_matches_base(u32 offset, ulong base)
+{
+ /* Try to write different values to RAM at two addresses */
+ writel(0, base);
+ writel(0xaa55aa55, base + offset);
+ dsb();
+ /* Check if the same value is actually observed when reading back */
+ return readl(base) ==
+ readl(base + offset);
+}
+
+static void mctl_auto_detect_dram_size_rank(uint16_t socid, struct dram_para
*para, ulong base, struct rank_para *rank)
{
/* detect row address bits */
- para->page_size = 512;
- para->row_bits = 16;
- para->bank_bits = 2;
+ rank->page_size = 512;
+ rank->row_bits = 16;
+ rank->bank_bits = 2;
mctl_set_cr(socid, para);
- for (para->row_bits = 11; para->row_bits < 16; para->row_bits++)
- if (mctl_mem_matches((1 << (para->row_bits + para->bank_bits))
* para->page_size))
+ for (rank->row_bits = 11; rank->row_bits < 16; rank->row_bits++)
+ if (mctl_mem_matches_base((1 << (rank->row_bits +
rank->bank_bits)) * rank->page_size, base))
break;
/* detect bank address bits */
- para->bank_bits = 3;
+ rank->bank_bits = 3;
mctl_set_cr(socid, para);
- for (para->bank_bits = 2; para->bank_bits < 3; para-&
[linux-sunxi] [PATCH 0/2] A64/R40 DRAM controller dual-rank-related changes
This patchset contains two patches. The first one enables asymmetric dual rank DRAM on A64. This is needed for 3GiB PinePhone, which has 2GiB rank 0 and 1GiB rank 1. This patch is already used by the firmware flashed to PinePhone by factory. The second one enables dual rank (and asymmetric dual rank, although not tested because of lack of real board) on R40. In order to support single rank and dual rank at the same time, a new rank detection code is implemented (because PIR_QSGATE-based one does not work on R40). The code enables some error report facility of the DRAM controller, and then tries to access rank 1 and then check for error. It's placed at 2nd patch because it depends on the function that calculates rank 0 size (and rank 1 base address) introduced in PATCH 1. Icenowy Zheng (2): sunxi: support asymmetric dual rank DRAM on A64/R40 sunxi: enable dual rank memory on R40 .../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 +- arch/arm/mach-sunxi/dram_sunxi_dw.c | 149 +++--- 2 files changed, 131 insertions(+), 29 deletions(-) -- 2.30.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210225161325.94019-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH v2 3/3] dt-bindings: arm: sunxi: document orig PineTab DT as sample
As the original PineTab DT (which uses sun50i-a64-pinetab name) is only
for development samples, document this.
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 8c62a1e2a498..7eec85be7ab9 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -695,7 +695,7 @@ properties:
- const: pine64,pinephone-1.2
- const: allwinner,sun50i-a64
- - description: Pine64 PineTab
+ - description: Pine64 PineTab, Development Sample
items:
- const: pine64,pinetab
- const: allwinner,sun50i-a64
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index 0494bfaf2ffa..422a8507f674 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -14,7 +14,7 @@
#include
/ {
- model = "PineTab";
+ model = "PineTab, Development Sample";
compatible = "pine64,pinetab", "allwinner,sun50i-a64";
aliases {
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201224024138.19422-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH v2 2/3] arm64: allwinner: dts: a64: add DT for Early Adopter's PineTab
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
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../sun50i-a64-pinetab-early-adopter.dts | 26 +++
2 files changed, 27 insertions(+)
create mode 100644
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..41ce680e5f8d 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-early-adopter.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
new file mode 100644
index ..652fc0cce304
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+ model = "PineTab, Early Adopter's version";
+ compatible = "pine64,pinetab-early-adopter", "allwinner,sun50i-a64";
+};
+
+&dsi {
+ /delete-node/ panel@0;
+
+ panel@0 {
+ compatible = "feixin,k101-im2byl02";
+ reg = <0>;
+ power-supply = <®_dc1sw>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ backlight = <&backlight>;
+ };
+};
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201224024001.19248-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH v2 1/3] dt-bindings: arm: sunxi: add PineTab Early Adopter edition
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: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 6db32fbf813f..8c62a1e2a498 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -700,6 +700,11 @@ properties: - const: pine64,pinetab - const: allwinner,sun50i-a64 + - description: Pine64 PineTab, Early Adopter's batch (and maybe later ones) +items: + - const: pine64,pinetab-early-adopter + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201224024001.19248-1-icenowy%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 1/3] dt-bindings: arm: sunxi: add PineTab new panel DT binding
在 2020-12-16星期三的 14:00 +0100，Maxime Ripard写道： > On Tue, Dec 15, 2020 at 06:59:33AM +0800, Icenowy Zheng wrote: > > 于 2020年12月14日 GMT+08:00 下午6:37:04, Maxime Ripard > > 写到: > > > On Thu, Dec 10, 2020 at 04:42:32PM +0800, Icenowy Zheng wrote: > > > > Early adopters' PineTabs (and all 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: Icenowy Zheng > > > > --- > > > > Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml > > > b/Documentation/devicetree/bindings/arm/sunxi.yaml > > > > index 6db32fbf813f..73a6c8421172 100644 > > > > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml > > > > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml > > > > @@ -700,6 +700,11 @@ properties: > > > >- const: pine64,pinetab > > > >- const: allwinner,sun50i-a64 > > > > > > > > + - description: Pine64 PineTab with new LCD panel > > > > +items: > > > > + - const: pine64,pinetab-new-panel > > > > + - const: allwinner,sun50i-a64 > > > > + > > > > > > We're on the right track, but new panel seems a bit too vague. > > > What is > > > going to happen when they will change the panel again? > > > > > > pinetab-early-adopter seems more robust there > > > > This name will only match a batch. > > Look, I know the situation sucks. Can we actually move forward? Descriptive name will match more things. I think we should still have something descriptive, even if "new panel" is too generic. > > Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/d0afbf23472f0e62517433eb273576937df65427.camel%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 1/3] dt-bindings: arm: sunxi: add PineTab new panel DT binding
于 2020年12月14日 GMT+08:00 下午6:37:04, Maxime Ripard 写到: >On Thu, Dec 10, 2020 at 04:42:32PM +0800, Icenowy Zheng wrote: >> Early adopters' PineTabs (and all 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: Icenowy Zheng >> --- >> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml >b/Documentation/devicetree/bindings/arm/sunxi.yaml >> index 6db32fbf813f..73a6c8421172 100644 >> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml >> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml >> @@ -700,6 +700,11 @@ properties: >>- const: pine64,pinetab >>- const: allwinner,sun50i-a64 >> >> + - description: Pine64 PineTab with new LCD panel >> +items: >> + - const: pine64,pinetab-new-panel >> + - const: allwinner,sun50i-a64 >> + > >We're on the right track, but new panel seems a bit too vague. What is >going to happen when they will change the panel again? > >pinetab-early-adopter seems more robust there This name will only match a batch. > >Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/7C38287D-F4E7-412A-A7F2-3787A1B04573%40aosc.io.
[linux-sunxi] Re: [PATCH v2 14/21] phy: sun4i-usb: Rework "pmu_unk1" handling
在 2020-12-14星期一的 01:35 +，André Przywara写道：
> On 13/12/2020 18:24, Icenowy Zheng wrote:
> > 在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
> > > Newer SoCs (A100, H616) need to clear a different bit in our
> > > "unknown"
> > > PMU PHY register.
> >
> > It looks like that the unknown PHY register is PHYCTL register for
> > each
> > individual PHY, and the bit that is cleared is
> > called SUNXI_HCI_PHY_CTRL_SIDDQ in the BSP (similar to
> > the USBC_PHY_CTL_SIDDQ we cleared for main PHYCTL).
In addition, both the BIT(1) in old PHYs and the BIT(3) in new PHYs are
SIDDQ. (In BSP it's a #define inside #if)
Should we add some flag for 28nm PHY?
>
> Oh, right, somehow I failed to find this in the BSP, I guess I got
> confused over that similar symbol. I will put proper names to it.
In addition, the region at 0x800 is not PMU at all, but some [OE]HCI-
related control registers. The name "PMU" can only cover the first
register here.
We may need to address this.
>
> Thanks!
> Andre
>
> > > Generalise the existing code by allowing configs to specify a
> > > bitmask
> > > of bits to clear.
> > >
> > > Signed-off-by: Andre Przywara
> > > ---
> > > drivers/phy/allwinner/phy-sun4i-usb.c | 28 +++
> > >
> > >
> > > 1 file changed, 11 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> > > b/drivers/phy/allwinner/phy-sun4i-usb.c
> > > index 651d5e2a25ce..4ba0699e0bb4 100644
> > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> > > @@ -115,9 +115,9 @@ struct sun4i_usb_phy_cfg {
> > > int hsic_index;
> > > enum sun4i_usb_phy_type type;
> > > u32 disc_thresh;
> > > + u32 pmu_unk1_clrbits;
> > > u8 phyctl_offset;
> > > bool dedicated_clocks;
> > > - bool enable_pmu_unk1;
> > > bool phy0_dual_route;
> > > int missing_phys;
> > > };
> > > @@ -288,6 +288,12 @@ static int sun4i_usb_phy_init(struct phy
> > > *_phy)
> > > return ret;
> > > }
> > >
> > > + if (phy->pmu && data->cfg->pmu_unk1_clrbits) {
> > > + val = readl(phy->pmu + REG_PMU_UNK1);
> > > + val &= ~data->cfg->pmu_unk1_clrbits;
> > > + writel(val, phy->pmu + REG_PMU_UNK1);
> > > + }
> > > +
> > > if (data->cfg->type == sun8i_a83t_phy ||
> > > data->cfg->type == sun50i_h6_phy) {
> > > if (phy->index == 0) {
> > > @@ -297,11 +303,6 @@ static int sun4i_usb_phy_init(struct phy
> > > *_phy)
> > > writel(val, data->base + data->cfg-
> > > > phyctl_offset);
> > > }
> > > } else {
> > > - if (phy->pmu && data->cfg->enable_pmu_unk1) {
> > > - val = readl(phy->pmu + REG_PMU_UNK1);
> > > - writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> > > - }
> > > -
> > > /* Enable USB 45 Ohm resistor calibration */
> > > if (phy->index == 0)
> > > sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN,
> > > 0x01, 1);
> > > @@ -867,7 +868,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun4i_a10_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = false,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
> > > @@ -876,7 +876,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun5i_a13_cfg = {
> > > .disc_thresh = 2,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = false,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
> > > @@ -885,7 +884,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun6i_a31_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = true,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
> > > @@ -894,7 +892,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun7i_a20_cfg = {
> > > .disc_thresh = 2,
[linux-sunxi] Re: [PATCH v2 14/21] phy: sun4i-usb: Rework "pmu_unk1" handling
在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
> Newer SoCs (A100, H616) need to clear a different bit in our
> "unknown"
> PMU PHY register.
It looks like that the unknown PHY register is PHYCTL register for each
individual PHY, and the bit that is cleared is
called SUNXI_HCI_PHY_CTRL_SIDDQ in the BSP (similar to
the USBC_PHY_CTL_SIDDQ we cleared for main PHYCTL).
>
> Generalise the existing code by allowing configs to specify a bitmask
> of bits to clear.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/phy/allwinner/phy-sun4i-usb.c | 28 +++
>
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 651d5e2a25ce..4ba0699e0bb4 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -115,9 +115,9 @@ struct sun4i_usb_phy_cfg {
> int hsic_index;
> enum sun4i_usb_phy_type type;
> u32 disc_thresh;
> + u32 pmu_unk1_clrbits;
> u8 phyctl_offset;
> bool dedicated_clocks;
> - bool enable_pmu_unk1;
> bool phy0_dual_route;
> int missing_phys;
> };
> @@ -288,6 +288,12 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> return ret;
> }
>
> + if (phy->pmu && data->cfg->pmu_unk1_clrbits) {
> + val = readl(phy->pmu + REG_PMU_UNK1);
> + val &= ~data->cfg->pmu_unk1_clrbits;
> + writel(val, phy->pmu + REG_PMU_UNK1);
> + }
> +
> if (data->cfg->type == sun8i_a83t_phy ||
> data->cfg->type == sun50i_h6_phy) {
> if (phy->index == 0) {
> @@ -297,11 +303,6 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> writel(val, data->base + data->cfg-
> >phyctl_offset);
> }
> } else {
> - if (phy->pmu && data->cfg->enable_pmu_unk1) {
> - val = readl(phy->pmu + REG_PMU_UNK1);
> - writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> - }
> -
> /* Enable USB 45 Ohm resistor calibration */
> if (phy->index == 0)
> sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN,
> 0x01, 1);
> @@ -867,7 +868,6 @@ static const struct sun4i_usb_phy_cfg
> sun4i_a10_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = false,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
> @@ -876,7 +876,6 @@ static const struct sun4i_usb_phy_cfg
> sun5i_a13_cfg = {
> .disc_thresh = 2,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = false,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
> @@ -885,7 +884,6 @@ static const struct sun4i_usb_phy_cfg
> sun6i_a31_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
> @@ -894,7 +892,6 @@ static const struct sun4i_usb_phy_cfg
> sun7i_a20_cfg = {
> .disc_thresh = 2,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = false,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
> @@ -903,7 +900,6 @@ static const struct sun4i_usb_phy_cfg
> sun8i_a23_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
> @@ -912,7 +908,6 @@ static const struct sun4i_usb_phy_cfg
> sun8i_a33_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun8i_a83t_cfg = {
> @@ -929,7 +924,7 @@ static const struct sun4i_usb_phy_cfg
> sun8i_h3_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = true,
> + .pmu_unk1_clrbits = BIT(1),
> .phy0_dual_route = true,
> };
>
> @@ -939,7 +934,7 @@ static const struct sun4i_usb_phy_cfg
> sun8i_r40_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = true,
> + .pmu_unk1_clrbits = BIT(1),
> .phy0_dual_route = true,
> };
>
> @@ -949,7 +944,7 @@ static const struct sun4i_usb_phy_cfg
> sun8i_v3s_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = true,
> + .pmu_unk1_clrbits = BIT(1),
> .phy0_dual_route = true,
> };
>
> @@ -959,7 +954,7 @@ static const struct sun4i_usb_phy_cfg
> sun50i_a64_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks =
[linux-sunxi] Re: [PATCH v2 00/21] arm64: sunxi: Initial Allwinner H616 SoC support
在 2020-12-11星期五的 01:19 +，Andre Przywara写道： > Hi, > > this is the quite expanded second version of the support series for > the > Allwinner H616 SoC. > Besides many fixes for the bugs discovered by the diligent reviewers > (many thanks for that!) this version adds some patches to support > some > slightly changed devices, like the second EMAC and the AXP not having > an interrupt. > Also I added quite some DT binding doc patches. > USB still does not work, but I include the patches anyway, hoping > that > someone can help spotting the issue. > For a more detailed changelog see below. > > Thanks! > Andre > > == > This series gathers patches to support the Allwinner H616 SoC. This > is > a rather uninspired SoC (Quad-A53 with the usual peripherals), but > allows for some cheap development boards and TV boxes, and supports > up to 4GB of DRAM. > > Various DT binding patches are sprinkled throughout the series, to > add > the new compatible names right before they are used. > Patch 1/21 is the usual drive-by fix, discovered while staring at > the H6 clock code. > Patch 3 and 4 add pinctrl support, with the "-R" controller now being > crippled down to two I2C pins only. If we grow tired of repeating > this > exercise for every new SoC variant, I am happy to revive my more > versatile sunxi pinctrl driver effort from a few years back [1]. > Patch 6 and 7 add clock support. For the -R clock this is shared with > the H6 code, as the clocks are identical, with the H616 just having > fewer of them. The main clocks are different enough to warrant a > separate > file. > Patch 08/21 is pulling a patch from Yangtao's A100 series, since we > need > the same fix for MMC support. This will probably be merged > separately, > I just include this here to provide a bootable solution. > Patch 10 teaches the AXP MFD driver to get along without having an > interrupt, as the H616 apparently does not have an NMI controller > anymore. > Patch 12 and 13 add some tweaks to the syscon and EMAC driver, to > deal > with the second EMAC clock used for the second Ethernet controller. > Patches 14 and 15 *try* to add USB support. The same approach works > with > the very similar U-Boot PHY driver, but for some reason still fail in > Linux. Maybe someone spots the issue and can help fixing it? There's a judge currently checks for phy type A83T/H6. You may need to add H616 there. Or should we have a bool in the data struct to mark it? I think all chips that need that is 28nm. > > The remaining patches add DT bindings, which just add the new > compatible > string along with an existing name as a fallback string. > Eventually we get the .dtsi for the SoC in patch 19, and the .dts for > the OrangePi Zero2 board[2] in the last patch. > > We have U-Boot and Trusted-Firmware support in a working state, > booting > via FEL and even TFTPing kernels work already [3][4]. > > Many thanks to Jernej for his tremendous help on this, also for the > awesome input and help from the #linux-sunxi Freenode channel. > > The whole series can also be found here: > https://github.com/apritzel/linux/commits/h616-v2 > > Happy reviewing! > > Cheers, > Andre > > [1] > https://patchwork.ozlabs.org/project/linux-gpio/cover/20171113012523.2328-1-andre.przyw...@arm.com/ > [2] https://linux-sunxi.org/Xunlong_Orange_Pi_Zero2 > [3] https://github.com/jernejsk/u-boot/commits/h616-v1 > [4] https://github.com/apritzel/arm-trusted-firmware/commits/h616-WIP > > Changelog v1 .. v2: > - pinctrl: adjust irq bank map to cover undocumented GPIO bank IRQs > - use differing h_i2s0 pin output names > - r-ccu: fix number of used clocks > - ccu: remove PLL-PERIPHy(4X) > - ccu: fix gpu1 divider range > - ccu: fix usb-phy3 parent > - ccu: add missing TV clocks > - ccu: rework to CLK_OF_DECLARE style > - ccu: enable output bit for PLL clocks > - ccu: renumber clocks > - .dtsi: drop sun50i-a64-system-control fallback > - .dtsi: drop unknown SRAM regions > - .dtsi: add more (undocumented) GPIO interrupts > - .dtsi: fix I2C3 pin names > - .dtsi: use a100-emmc fallback for MMC2 > - .dtsi: add second EMAC controller > - .dtsi: use H3 MUSB controller fallback > - .dtsi: fix frame size for USB PHY PMU registers > - .dtsi: add USB0 PHY references > - .dtsi: fix IR controller clock source > - .dts: fix LED naming and swap pins > - .dts: use 5V supply parent for USB supply > - .dts: drop dummy IRQ for AXP > - .dts: enable 3V3 header pin power rail > - .dts: add SPI flash node > - .dts: make USB-C port peripheral only > - add IRQ-less AXP support > - add two patches to support more than one EMAC clock > - add patch to rework and extend USB PHY support > - add DT binding documentation patches > > Andre Przywara (18): > clk: sunxi-ng: h6: Fix clock divider range on some clocks > dt-bindings: pinctrl: Add Allwinner H616 compatible strings > pinctrl: sunxi: Add support for the Allwinner H616 pin controller > pinctrl: sunxi: Add support for the Allwinner H616-R pin c
[linux-sunxi] Re: [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
> Port A is used for an internal connection to some analogue circuitry
> which looks like an AC200 IP (as in the H6), though this is not
> mentioned in the manual.
When developing for V831, I found that PIO controller in H616 (and
V831) has the functionality of selecting IO voltage of PF bank (needed
to handle UHS-I).
How should we model this in PIO driver?
>
> Signed-off-by: Andre Przywara
> ---
> drivers/pinctrl/sunxi/Kconfig | 5 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 549
>
> 3 files changed, 555 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig
> b/drivers/pinctrl/sunxi/Kconfig
> index 593293584ecc..73e88ce71a48 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -119,4 +119,9 @@ config PINCTRL_SUN50I_H6_R
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_H616
> + bool "Support for the Allwinner H616 PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> endif
> diff --git a/drivers/pinctrl/sunxi/Makefile
> b/drivers/pinctrl/sunxi/Makefile
> index 8b7ff0dc3bdf..5359327a3c8f 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -23,5 +23,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_V3S) +=
> pinctrl-sun8i-v3s.o
> obj-$(CONFIG_PINCTRL_SUN50I_H5) += pinctrl-sun50i-h5.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6) += pinctrl-sun50i-h6.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6_R)+= pinctrl-sun50i-h6-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H616)+= pinctrl-sun50i-h616.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R)+= pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> new file mode 100644
> index ..734f63eb08dd
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> @@ -0,0 +1,549 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Allwinner H616 SoC pinctrl driver.
> + *
> + * Copyright (C) 2020 Arm Ltd.
> + * based on the H6 pinctrl driver
> + * Copyright (C) 2017 Icenowy Zheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin h616_pins[] = {
> + /* Internal connection to the AC200 part */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ECRS_DV */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXEN */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> + SUNXI_FUNCTION(0x2, "emac1")), /* EMDC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> + SUNXI_FUNCTION(0x2, "emac1")), /* EMDIO */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> + SUNXI_FUNCTION(0x2, "i2c3")), /* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> + SUNXI_FUNCTION(0x2, "i2c3")), /* SDA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> + SUNXI_FUNCTION(0x2, "pwm5")),
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PC_EINT0
> */
> + SUNX
Re: [linux-sunxi] [PATCH 5/8] clk: sunxi-ng: Add support for the Allwinner H616 CCU
在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
> While the clocks are fairly similar to the H6, many differ in tiny
> details, so a separate clock driver seems indicated.
>
> Derived from the H6 clock driver, and adjusted according to the
> manual.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/clk/sunxi-ng/Kconfig|7 +-
> drivers/clk/sunxi-ng/Makefile |1 +
> drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 1134
> +++
> drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 58 +
> include/dt-bindings/clock/sun50i-h616-ccu.h | 110 ++
> include/dt-bindings/reset/sun50i-h616-ccu.h | 67 ++
> 6 files changed, 1376 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> create mode 100644 include/dt-bindings/clock/sun50i-h616-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-h616-ccu.h
>
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-
> ng/Kconfig
> index ce5f5847d5d3..cd46d8853876 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -32,8 +32,13 @@ config SUN50I_H6_CCU
> default ARM64 && ARCH_SUNXI
> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>
> +config SUN50I_H616_CCU
> + bool "Support for the Allwinner H616 CCU"
> + default ARM64 && ARCH_SUNXI
> + depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> +
> config SUN50I_H6_R_CCU
> - bool "Support for the Allwinner H6 PRCM CCU"
> + bool "Support for the Allwinner H6 and H616 PRCM CCU"
> default ARM64 && ARCH_SUNXI
> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-
> ng/Makefile
> index 3eb5cff40eac..96c324306d97 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_SUN50I_A64_CCU)+= ccu-sun50i-
> a64.o
> obj-$(CONFIG_SUN50I_A100_CCU)+= ccu-sun50i-a100.o
> obj-$(CONFIG_SUN50I_A100_R_CCU) += ccu-sun50i-a100-r.o
> obj-$(CONFIG_SUN50I_H6_CCU) += ccu-sun50i-h6.o
> +obj-$(CONFIG_SUN50I_H616_CCU)+= ccu-sun50i-h616.o
> obj-$(CONFIG_SUN50I_H6_R_CCU)+= ccu-sun50i-h6-r.o
> obj-$(CONFIG_SUN4I_A10_CCU) += ccu-sun4i-a10.o
> obj-$(CONFIG_SUN5I_CCU) += ccu-sun5i.o
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> new file mode 100644
> index 0000..3fbb258f0354
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> @@ -0,0 +1,1134 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Arm Ltd.
> + * Based on the H6 CCU driver, which is:
> + * Copyright (c) 2017 Icenowy Zheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ccu_common.h"
> +#include "ccu_reset.h"
> +
> +#include "ccu_div.h"
> +#include "ccu_gate.h"
> +#include "ccu_mp.h"
> +#include "ccu_mult.h"
> +#include "ccu_nk.h"
> +#include "ccu_nkm.h"
> +#include "ccu_nkmp.h"
> +#include "ccu_nm.h"
> +
> +#include "ccu-sun50i-h616.h"
> +
> +/*
> + * The CPU PLL is actually NP clock, with P being /1, /2 or /4.
> However
> + * P should only be used for output frequencies lower than 288 MHz.
> + *
> + * For now we can just model it as a multiplier clock, and force P
> to /1.
> + *
> + * The M factor is present in the register's description, but not in
> the
> + * frequency formula, and it's documented as "M is only used for
> backdoor
> + * testing", so it's not modelled and then force to 0.
> + */
> +#define SUN50I_H616_PLL_CPUX_REG 0x000
> +static struct ccu_mult pll_cpux_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
> + .mult = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> + .common = {
> + .reg= 0x000,
> + .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
> + &ccu_mult_ops,
> + CLK_SET_RATE_UNGATE),
> + },
> +};
> +
> +/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K
> */
> +#define SUN50I_H616_PLL_DDR0_REG 0x010
> +static struct ccu_nkmp pll_ddr0_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
> + .n = _SUNXI_C
[linux-sunxi] [PATCH 3/3] dt-bindings: arm: sunxi: note that old PineTab compatible has old panel
As the old LCD panel used by PineTab developer samples are discontinued, there won't be furtherly any more units of the sample, and this should be noted in the document. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 73a6c8421172..9f29b5811aa1 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -695,7 +695,7 @@ properties: - const: pine64,pinephone-1.2 - const: allwinner,sun50i-a64 - - description: Pine64 PineTab + - description: Pine64 PineTab (developers' sample with old discontinued LCD panel, discontinued) items: - const: pine64,pinetab - const: allwinner,sun50i-a64 -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201210084558.1917246-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 2/3] arm64: allwinner: dts: a64: add DT for PineTab with new LCD panel
Further released PineTabs will have a new LCD panel that is different
with the one used in developers' samples.
Add device tree for PineTab with the new panel.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../sun50i-a64-pinetab-new-panel.dts | 26 +++
2 files changed, 27 insertions(+)
create mode 100644
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..83c6d1ea197f 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-new-panel.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts
new file mode 100644
index ..f3da9653be3e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+ model = "PineTab with new LCD panel";
+ compatible = "pine64,pinetab-new-panel", "allwinner,sun50i-a64";
+};
+
+&dsi {
+ /delete-node/ panel@0;
+
+ panel@0 {
+ compatible = "feixin,k101-im2byl02";
+ reg = <0>;
+ power-supply = <®_dc1sw>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ backlight = <&backlight>;
+ };
+};
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201210084450.1915234-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 1/3] dt-bindings: arm: sunxi: add PineTab new panel DT binding
Early adopters' PineTabs (and all 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: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 6db32fbf813f..73a6c8421172 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -700,6 +700,11 @@ properties: - const: pine64,pinetab - const: allwinner,sun50i-a64 + - description: Pine64 PineTab with new LCD panel +items: + - const: pine64,pinetab-new-panel + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201210084232.1913871-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 0/3] PineTab with new panel DT
As discussed on the mailing list, here introduces a new DT for new PineTabs. Icenowy Zheng (3): dt-bindings: arm: sunxi: add PineTab new panel DT binding arm64: allwinner: dts: a64: add DT for PineTab with new LCD panel dt-bindings: arm: sunxi: note that old PineTab compatible has old panel .../devicetree/bindings/arm/sunxi.yaml| 7 - arch/arm64/boot/dts/allwinner/Makefile| 1 + .../sun50i-a64-pinetab-new-panel.dts | 26 +++ 3 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201210083722.1912981-1-icenowy%40aosc.io.
Re: [linux-sunxi] [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
于 2020年12月6日 GMT+08:00 下午10:52:17, "André Przywara" 写到:
>On 06/12/2020 12:42, Jernej Škrabec wrote:
>
>Hi,
>
>> Dne nedelja, 06. december 2020 ob 13:32:49 CET je Clément Péron
>napisal(a):
>>> Hi Andre,
>>>
>>> On Wed, 2 Dec 2020 at 14:54, Andre Przywara
>wrote:
>>>> Port A is used for an internal connection to some analogue
>circuitry
>>>> which looks like an AC200 IP (as in the H6), though this is not
>>>> mentioned in the manual.
>>>>
>>>> Signed-off-by: Andre Przywara
>>>> ---
>>>>
>>>> drivers/pinctrl/sunxi/Kconfig | 5 +
>>>> drivers/pinctrl/sunxi/Makefile | 1 +
>>>> drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 549
>
>>>> 3 files changed, 555 insertions(+)
>>>> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>>>>
>>>> diff --git a/drivers/pinctrl/sunxi/Kconfig
>b/drivers/pinctrl/sunxi/Kconfig
>>>> index 593293584ecc..73e88ce71a48 100644
>>>> --- a/drivers/pinctrl/sunxi/Kconfig
>>>> +++ b/drivers/pinctrl/sunxi/Kconfig
>>>> @@ -119,4 +119,9 @@ config PINCTRL_SUN50I_H6_R
>>>>
>>>> default ARM64 && ARCH_SUNXI
>>>> select PINCTRL_SUNXI
>>>>
>>>> +config PINCTRL_SUN50I_H616
>>>> + bool "Support for the Allwinner H616 PIO"
>>>> + default ARM64 && ARCH_SUNXI
>>>> + select PINCTRL_SUNXI
>>>> +
>>>>
>>>> endif
>>>>
>>>> diff --git a/drivers/pinctrl/sunxi/Makefile
>>>> b/drivers/pinctrl/sunxi/Makefile index 8b7ff0dc3bdf..5359327a3c8f
>100644
>>>> --- a/drivers/pinctrl/sunxi/Makefile
>>>> +++ b/drivers/pinctrl/sunxi/Makefile
>>>> @@ -23,5 +23,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_V3S) +=
>>>> pinctrl-sun8i-v3s.o>
>>>> obj-$(CONFIG_PINCTRL_SUN50I_H5)+=
>pinctrl-sun50i-h5.o
>>>> obj-$(CONFIG_PINCTRL_SUN50I_H6)+=
>pinctrl-sun50i-h6.o
>>>> obj-$(CONFIG_PINCTRL_SUN50I_H6_R) += pinctrl-sun50i-h6-r.o
>>>>
>>>> +obj-$(CONFIG_PINCTRL_SUN50I_H616) += pinctrl-sun50i-h616.o
>>>>
>>>> obj-$(CONFIG_PINCTRL_SUN9I_A80)+=
>pinctrl-sun9i-a80.o
>>>> obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
>>>>
>>>> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>>>> b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c new file mode 100644
>>>> index ..734f63eb08dd
>>>> --- /dev/null
>>>> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>>>> @@ -0,0 +1,549 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Allwinner H616 SoC pinctrl driver.
>>>> + *
>>>> + * Copyright (C) 2020 Arm Ltd.
>>>> + * based on the H6 pinctrl driver
>>>> + * Copyright (C) 2017 Icenowy Zheng
>>>> + */
>>>> +
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +
>>>> +#include "pinctrl-sunxi.h"
>>>> +
>>>> +static const struct sunxi_desc_pin h616_pins[] = {
>>>> + /* Internal connection to the AC200 part */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD1 */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD0 */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ECRS_DV
>*/
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXERR
>*/
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD1 */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD0 */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXCK */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
>>
Re: [linux-sunxi] Re: [PATCH 5/8] clk: sunxi-ng: Add support for the Allwinner H616 CCU
ne CLK_CPUX 23 > > > + > > > +#define CLK_APB1 28 > > > + > > > +#define CLK_DE 31 > > > +#define CLK_BUS_DE 32 > > > +#define CLK_DEINTERLACE 33 > > > +#define CLK_BUS_DEINTERLACE 34 > > > +#define CLK_G2D 35 > > > +#define CLK_BUS_G2D 36 > > > +#define CLK_GPU0 37 > > > +#define CLK_BUS_GPU 38 > > > +#define CLK_GPU1 39 > > > +#define CLK_CE 40 > > > +#define CLK_BUS_CE 41 > > > +#define CLK_VE 42 > > > +#define CLK_BUS_VE 43 > > > +#define CLK_BUS_DMA 44 > > > +#define CLK_BUS_HSTIMER 45 > > > +#define CLK_AVS 46 > > > +#define CLK_BUS_DBG 47 > > > +#define CLK_BUS_PSI 48 > > > +#define CLK_BUS_PWM 49 > > > +#define CLK_BUS_IOMMU50 > > > + > > > +#define CLK_MBUS_DMA 52 > > > +#define CLK_MBUS_VE 53 > > > +#define CLK_MBUS_CE 54 > > > +#define CLK_MBUS_TS 55 > > > +#define CLK_MBUS_NAND56 > > > +#define CLK_MBUS_G2D 57 > > > + > > > +#define CLK_NAND059 > > > +#define CLK_NAND160 > > > +#define CLK_BUS_NAND 61 > > > +#define CLK_MMC0 62 > > > +#define CLK_MMC1 63 > > > +#define CLK_MMC2 64 > > > +#define CLK_BUS_MMC0 65 > > > +#define CLK_BUS_MMC1 66 > > > +#define CLK_BUS_MMC2 67 > > > +#define CLK_BUS_UART068 > > > +#define CLK_BUS_UART169 > > > +#define CLK_BUS_UART270 > > > +#define CLK_BUS_UART371 > > > +#define CLK_BUS_UART472 > > > +#define CLK_BUS_UART573 > > > +#define CLK_BUS_I2C0 74 > > > +#define CLK_BUS_I2C1 75 > > > +#define CLK_BUS_I2C2 76 > > > +#define CLK_BUS_I2C3 77 > > > +#define CLK_BUS_I2C4 78 > > > +#define CLK_SPI0 79 > > > +#define CLK_SPI1 80 > > > +#define CLK_BUS_SPI0 81 > > > +#define CLK_BUS_SPI1 82 > > > +#define CLK_EMAC_25M 83 > > > +#define CLK_BUS_EMAC084 > > > +#define CLK_BUS_EMAC185 > > > +#define CLK_TS 86 > > > +#define CLK_BUS_TS 87 > > > +#define CLK_BUS_THS 88 > > > +#define CLK_SPDIF89 > > > +#define CLK_BUS_SPDIF90 > > > +#define CLK_DMIC 91 > > > +#define CLK_BUS_DMIC 92 > > > +#define CLK_AUDIO_CODEC_1X 93 > > > +#define CLK_AUDIO_CODEC_4X 94 > > > +#define CLK_BUS_AUDIO_CODEC 95 > > > +#define CLK_AUDIO_HUB96 > > > +#define CLK_BUS_AUDIO_HUB97 > > > +#define CLK_USB_OHCI098 > > > +#define CLK_USB_PHY0 99 > > > +#define CLK_USB_OHCI1100 > > > +#define CLK_USB_PHY1 101 > > > +#define CLK_USB_OHCI2102 > > > +#define CLK_USB_PHY2 103 > > > +#define CLK_USB_OHCI3104 > > > +#define CLK_USB_PHY3 105 > > > +#define CLK_BUS_OHCI0106 > > > +#define CLK_BUS_OHCI1107 > > > +#define CLK_BUS_OHCI2108 > > > +#define CLK_BUS_OHCI3109 > > > +#define CLK_BUS_EHCI0110 > > > +#define CLK_BUS_EHCI1111 > > > +#define CLK_BUS_EHCI2112 > > > +#define CLK_BUS_EHCI3113 > > > +#define CLK_BUS_OTG 114 > > > +#define CLK_BUS_KEYADC 115 > > > +#define CLK_HDMI 116 > > > +#define CLK_HDMI_SLOW117 > > > +#define CLK_HDMI_CEC 118 > > > +#define CLK_BUS_HDMI 119 > > > +#define CLK_BUS_TCON_TOP 120 > > > +#define CLK_TCON_TV0 121 > > > +#define CLK_BUS_TCON_TV0 122 > > > +#define CLK_HDCP 123 > > > +#define CLK_BUS_HDCP 124 > > > + > > > +#endif /* _DT_BINDINGS_CLK_SUN50I_H616_H_ */ > > > diff --git a/include/dt-bindings/reset/sun50i-h616-ccu.h >
Re: [linux-sunxi] Re: [PATCH 4/8] clk: sunxi-ng: Add support for the Allwinner H616 R-CCU
于 2020年12月3日 GMT+08:00 下午7:07:02, "André Przywara" 写到:
>On 02/12/2020 14:31, Icenowy Zheng wrote:
>
>Hi,
>
>> 于 2020年12月2日 GMT+08:00 下午9:54:05, Andre Przywara
> 写到:
>>> The clocks itself are identical to the H6 R-CCU, it's just that the
>>> H616
>>> has not all of them implemented (or connected).
>>
>> For selective clocks, try to follow the practice of V3(s) driver?
>
>Not sure what you mean, isn't that what I do? Having a separate
>sunxi_ccu_desc for each SoC and referencing separate structs? At least
>that's what I see in ccu-sun8i-v3s.c.
>
>What am I missing?
Sorry, I misred it.
Ignore my disturbance.
>
>Cheers,
>Andre
>
>>>
>>> Signed-off-by: Andre Przywara
>>> ---
>>> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 47
>+-
>>> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 3 +-
>>> 2 files changed, 48 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>>> b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>>> index 50f8d1bc7046..119d1797f501 100644
>>> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>>> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>>> @@ -136,6 +136,15 @@ static struct ccu_common
>*sun50i_h6_r_ccu_clks[] =
>>> {
>>> &w1_clk.common,
>>> };
>>>
>>> +static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
>>> + &r_apb1_clk.common,
>>> + &r_apb2_clk.common,
>>> + &r_apb1_twd_clk.common,
>>> + &r_apb2_i2c_clk.common,
>>> + &r_apb1_ir_clk.common,
>>> + &ir_clk.common,
>>> +};
>>> +
>>> static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
>>> .hws= {
>>> [CLK_AR100] = &ar100_clk.common.hw,
>>> @@ -152,7 +161,20 @@ static struct clk_hw_onecell_data
>>> sun50i_h6_r_hw_clks = {
>>> [CLK_IR]= &ir_clk.common.hw,
>>> [CLK_W1]= &w1_clk.common.hw,
>>> },
>>> - .num= CLK_NUMBER,
>>> + .num= CLK_NUMBER_H616,
>>> +};
>>> +
>>> +static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
>>> + .hws= {
>>> + [CLK_R_AHB] = &r_ahb_clk.hw,
>>> + [CLK_R_APB1]= &r_apb1_clk.common.hw,
>>> + [CLK_R_APB2]= &r_apb2_clk.common.hw,
>>> + [CLK_R_APB1_TWD]= &r_apb1_twd_clk.common.hw,
>>> + [CLK_R_APB2_I2C]= &r_apb2_i2c_clk.common.hw,
>>> + [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
>>> + [CLK_IR]= &ir_clk.common.hw,
>>> + },
>>> + .num= CLK_NUMBER_H616,
>>> };
>>>
>>> static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
>>> @@ -165,6 +187,12 @@ static struct ccu_reset_map
>>> sun50i_h6_r_ccu_resets[] = {
>>> [RST_R_APB1_W1] = { 0x1ec, BIT(16) },
>>> };
>>>
>>> +static struct ccu_reset_map sun50i_h616_r_ccu_resets[] = {
>>> + [RST_R_APB1_TWD]= { 0x12c, BIT(16) },
>>> + [RST_R_APB2_I2C]= { 0x19c, BIT(16) },
>>> + [RST_R_APB1_IR] = { 0x1cc, BIT(16) },
>>> +};
>>> +
>>> static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc = {
>>> .ccu_clks = sun50i_h6_r_ccu_clks,
>>> .num_ccu_clks = ARRAY_SIZE(sun50i_h6_r_ccu_clks),
>>> @@ -175,6 +203,16 @@ static const struct sunxi_ccu_desc
>>> sun50i_h6_r_ccu_desc = {
>>> .num_resets = ARRAY_SIZE(sun50i_h6_r_ccu_resets),
>>> };
>>>
>>> +static const struct sunxi_ccu_desc sun50i_h616_r_ccu_desc = {
>>> + .ccu_clks = sun50i_h616_r_ccu_clks,
>>> + .num_ccu_clks = ARRAY_SIZE(sun50i_h616_r_ccu_clks),
>>> +
>>> + .hw_clks= &sun50i_h616_r_hw_clks,
>>> +
>>> + .resets = sun50i_h616_r_ccu_resets,
>>> + .num_resets = ARRAY_SIZE(sun50i_h616_r_ccu_resets),
>>> +};
>>> +
>>> static void __init sunxi_r_ccu_init(struct device_node *node,
>>> const struct sunxi_ccu_desc *desc)
>>> {
>>> @@ -195,3 +233,10 @@ static void __init sun50i_h6_r_ccu_setup(struct
>>> device_node *node)
>>> }
>>> CLK_OF_DECLARE(sun50i_h6_r_ccu, "allwinner,sun50i-h6-r-ccu",
>>
[linux-sunxi] Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
于 2020年12月3日 GMT+08:00 上午12:05:04, Maxime Ripard 写到:
>On Wed, Dec 02, 2020 at 01:54:08PM +, Andre Przywara wrote:
>> This (relatively) new SoC is similar to the H6, but drops the
>(broken)
>> PCIe support and the USB 3.0 controller. It also gets the management
>> controller removed, which in turn removes *some*, but not all of the
>> devices formerly dedicated to the ARISC (CPUS).
>> There does not seem to be an external interrupt controller anymore,
>so
>> no external interrupts through an NMI pin. The AXP driver needs to
>learn
>> living with that.
>>
>> Signed-off-by: Andre Przywara
>> ---
>> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 704
>++
>> 1 file changed, 704 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>> new file mode 100644
>> index ..dcffbfdcd26b
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>> @@ -0,0 +1,704 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +// Copyright (C) 2020 Arm Ltd.
>> +// based on the H6 dtsi, which is:
>> +// Copyright (C) 2017 Icenowy Zheng
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/ {
>> +interrupt-parent = <&gic>;
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +
>> +cpus {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +cpu0: cpu@0 {
>> +compatible = "arm,cortex-a53";
>> +device_type = "cpu";
>> +reg = <0>;
>> +enable-method = "psci";
>> +clocks = <&ccu CLK_CPUX>;
>> +};
>> +
>> +cpu1: cpu@1 {
>> +compatible = "arm,cortex-a53";
>> +device_type = "cpu";
>> +reg = <1>;
>> +enable-method = "psci";
>> +clocks = <&ccu CLK_CPUX>;
>> +};
>> +
>> +cpu2: cpu@2 {
>> +compatible = "arm,cortex-a53";
>> +device_type = "cpu";
>> +reg = <2>;
>> +enable-method = "psci";
>> +clocks = <&ccu CLK_CPUX>;
>> +};
>> +
>> +cpu3: cpu@3 {
>> +compatible = "arm,cortex-a53";
>> +device_type = "cpu";
>> +reg = <3>;
>> +enable-method = "psci";
>> +clocks = <&ccu CLK_CPUX>;
>> +};
>> +};
>> +
>> +reserved-memory {
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +ranges;
>> +
>> +/* 512KiB reserved for ARM Trusted Firmware (BL31) */
>> +secmon_reserved: secmon@4000 {
>> +reg = <0x0 0x4000 0x0 0x8>;
>> +no-map;
>> +};
>> +};
>
>I'm not sure why that node is there, the previous SoCs didn't have it?
Previously we (ab)use SRAM A2 (designed for ARISC) for ATF.
But H616 has no SRAM A2.
>Shouldn't ATF patch it itself?
>
>> +osc24M: osc24M_clk {
>> +#clock-cells = <0>;
>> +compatible = "fixed-clock";
>> +clock-frequency = <2400>;
>> +clock-output-names = "osc24M";
>> +};
>> +
>> +pmu {
>> +compatible = "arm,cortex-a53-pmu";
>> +interrupts = ,
>> + ,
>> + ,
>> + ;
>> +interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
>> +};
>> +
>> +psci {
>> +compatible = "arm,psci-0.2";
>> +method = "smc";
>> +};
>> +
>> +timer {
>> +compatible = "arm,armv8-timer";
>> +arm,no-tick-in-suspend;
>
>
[linux-sunxi] Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
> This (relatively) new SoC is similar to the H6, but drops the
> (broken)
> PCIe support and the USB 3.0 controller. It also gets the management
> controller removed, which in turn removes *some*, but not all of the
> devices formerly dedicated to the ARISC (CPUS).
> There does not seem to be an external interrupt controller anymore,
> so
> no external interrupts through an NMI pin. The AXP driver needs to
> learn
> living with that.
>
> Signed-off-by: Andre Przywara
> ---
> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 704
> ++
> 1 file changed, 704 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> new file mode 100644
> index ..dcffbfdcd26b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -0,0 +1,704 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2020 Arm Ltd.
> +// based on the H6 dtsi, which is:
> +// Copyright (C) 2017 Icenowy Zheng
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu2: cpu@2 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu3: cpu@3 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> + secmon_reserved: secmon@4000 {
> + reg = <0x0 0x4000 0x0 0x8>;
> + no-map;
> + };
Should this node be dynamically added by the firmware? This is only
some effort taken by our community, not from Allwinner. (Although
Allwinner reserves much more memory in their BSP.)
(In my opinion, it should be applied by ATF to U-Boot DT, and then U-
Boot add it to Linux DT.)
> + };
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2400>;
> + clock-output-names = "osc24M";
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = ,
> + ,
> + ,
> + ;
> + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>,
> <&cpu3>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + arm,no-tick-in-suspend;
> + interrupts = + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
&
[linux-sunxi] Re: [PATCH 8/8] arm64: dts: allwinner: Add OrangePi Zero 2 .dts
在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
> The OrangePi Zero 2 is a development board with the new H616 SoC.
>
> It features the usual connectors used on those small boards, and
> comes
> with the AXP305, which seems to be compatible with the AXP805.
>
> For more details see: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero2
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm64/boot/dts/allwinner/Makefile| 1 +
> .../allwinner/sun50i-h616-orangepi-zero2.dts | 228
> ++
> 2 files changed, 229 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-
> orangepi-zero2.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> index 211d1e9d4701..0cf8299b1ce7 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -35,3 +35,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-
> plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
> zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
> zero2.dts
> new file mode 100644
> index ..814f5b4fec7c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> @@ -0,0 +1,228 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2020 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "OrangePi Zero2";
> + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
> +
> + aliases {
> + ethernet0 = &emac0;
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "orangepi:red:power";
> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13
> */
> + default-state = "on";
> + };
> +
> + status {
> + label = "orangepi:green:status";
> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12
> */
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the USB-C socket
> */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };
> +
> + reg_usb1_vbus: usb1-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb1-vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + enable-active-high;
> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> + status = "okay";
> + };
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +/* USB 2 & 3 are on headers only. */
> +
> +&emac0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ext_rgmii_pins>;
> + phy-mode = "rgmii";
> + phy-handle = <&ext_rgmii_phy>;
> + phy-supply = <®_dcdce>;
> + allwinner,rx-delay-ps = <3100>;
> + allwinner,tx-delay-ps = <700>;
> + status = "okay";
> +};
> +
> +&mdio {
> + ext_rgmii_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdce>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp305: pmic@36 {
> + compatible = "x-powers,axp305", "x-powers,axp805",
> + "x-powers,axp806";
> + reg = <0x36>;
> +
> + /* dummy interrupt to appease the driver for now */
> + interrupts = ;
> + interrupt-controller;
> + #interrupt-cells = <1>;
Is dummy interrupt future-proof?
> +
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
> +
> + regulators {
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> +
[linux-sunxi] Re: [PATCH 4/8] clk: sunxi-ng: Add support for the Allwinner H616 R-CCU
于 2020年12月2日 GMT+08:00 下午9:54:05, Andre Przywara 写到:
>The clocks itself are identical to the H6 R-CCU, it's just that the
>H616
>has not all of them implemented (or connected).
For selective clocks, try to follow the practice of V3(s) driver?
>
>Signed-off-by: Andre Przywara
>---
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 47 +-
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 3 +-
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>index 50f8d1bc7046..119d1797f501 100644
>--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>@@ -136,6 +136,15 @@ static struct ccu_common *sun50i_h6_r_ccu_clks[] =
>{
> &w1_clk.common,
> };
>
>+static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
>+ &r_apb1_clk.common,
>+ &r_apb2_clk.common,
>+ &r_apb1_twd_clk.common,
>+ &r_apb2_i2c_clk.common,
>+ &r_apb1_ir_clk.common,
>+ &ir_clk.common,
>+};
>+
> static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
> .hws= {
> [CLK_AR100] = &ar100_clk.common.hw,
>@@ -152,7 +161,20 @@ static struct clk_hw_onecell_data
>sun50i_h6_r_hw_clks = {
> [CLK_IR]= &ir_clk.common.hw,
> [CLK_W1]= &w1_clk.common.hw,
> },
>- .num= CLK_NUMBER,
>+ .num= CLK_NUMBER_H616,
>+};
>+
>+static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
>+ .hws= {
>+ [CLK_R_AHB] = &r_ahb_clk.hw,
>+ [CLK_R_APB1]= &r_apb1_clk.common.hw,
>+ [CLK_R_APB2]= &r_apb2_clk.common.hw,
>+ [CLK_R_APB1_TWD]= &r_apb1_twd_clk.common.hw,
>+ [CLK_R_APB2_I2C]= &r_apb2_i2c_clk.common.hw,
>+ [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
>+ [CLK_IR]= &ir_clk.common.hw,
>+ },
>+ .num= CLK_NUMBER_H616,
> };
>
> static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
>@@ -165,6 +187,12 @@ static struct ccu_reset_map
>sun50i_h6_r_ccu_resets[] = {
> [RST_R_APB1_W1] = { 0x1ec, BIT(16) },
> };
>
>+static struct ccu_reset_map sun50i_h616_r_ccu_resets[] = {
>+ [RST_R_APB1_TWD]= { 0x12c, BIT(16) },
>+ [RST_R_APB2_I2C]= { 0x19c, BIT(16) },
>+ [RST_R_APB1_IR] = { 0x1cc, BIT(16) },
>+};
>+
> static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc = {
> .ccu_clks = sun50i_h6_r_ccu_clks,
> .num_ccu_clks = ARRAY_SIZE(sun50i_h6_r_ccu_clks),
>@@ -175,6 +203,16 @@ static const struct sunxi_ccu_desc
>sun50i_h6_r_ccu_desc = {
> .num_resets = ARRAY_SIZE(sun50i_h6_r_ccu_resets),
> };
>
>+static const struct sunxi_ccu_desc sun50i_h616_r_ccu_desc = {
>+ .ccu_clks = sun50i_h616_r_ccu_clks,
>+ .num_ccu_clks = ARRAY_SIZE(sun50i_h616_r_ccu_clks),
>+
>+ .hw_clks= &sun50i_h616_r_hw_clks,
>+
>+ .resets = sun50i_h616_r_ccu_resets,
>+ .num_resets = ARRAY_SIZE(sun50i_h616_r_ccu_resets),
>+};
>+
> static void __init sunxi_r_ccu_init(struct device_node *node,
> const struct sunxi_ccu_desc *desc)
> {
>@@ -195,3 +233,10 @@ static void __init sun50i_h6_r_ccu_setup(struct
>device_node *node)
> }
> CLK_OF_DECLARE(sun50i_h6_r_ccu, "allwinner,sun50i-h6-r-ccu",
> sun50i_h6_r_ccu_setup);
>+
>+static void __init sun50i_h616_r_ccu_setup(struct device_node *node)
>+{
>+ sunxi_r_ccu_init(node, &sun50i_h616_r_ccu_desc);
>+}
>+CLK_OF_DECLARE(sun50i_h616_r_ccu, "allwinner,sun50i-h616-r-ccu",
>+ sun50i_h616_r_ccu_setup);
>diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>index 782117dc0b28..128302696ca1 100644
>--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>@@ -14,6 +14,7 @@
>
> #define CLK_R_APB23
>
>-#define CLK_NUMBER(CLK_W1 + 1)
>+#define CLK_NUMBER_H6 (CLK_W1 + 1)
>+#define CLK_NUMBER_H616 (CLK_IR + 1)
>
> #endif /* _CCU_SUN50I_H6_R_H */
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/422A0729-7E7C-4ABF-BEAB-21772FDD0CE3%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" 写到: >Hi Icenowy, > >On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng wrote: >> >> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道： >> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: >> > > > > > > > Okay. But I'm not satisfied with a non-public sample >> > > > > > > > occupies >> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a >> > > > > > > > pinetab-retail okay? >> > > > > > > >> > > > > > > To me, naming the production version anything but >"pinetab" >> > > > > > > isn't >> > > > > > > satisfying either. >> > > > > > >> > > > > > I understand where you're coming from, but the point I was >> > > > > > making my >> > > > > > previous mail is precisely that it's not really possible. >> > > > > > >> > > > > > You want to name the early adopter version _the_ production >> > > > > > version. Let's assume the hardware changes again between >the >> > > > > > early >> > > > > > adopter and mass-production version. Which one will be >_the_ >> > > > > > production version? The early-adopter or the mass-produced >> > > > > > one? >> > > > > > >> > > > > > There's really no good answer here, and both would suck in >> > > > > > their >> > > > > > own way. The only way to deal with this is to simply avoid >> > > > > > defining one version as the one true board, and just >loading >> > > > > > the >> > > > > > proper DT in u-boot based on whatever clue we have of the >> > > > > > hardware >> > > > > > revision. >> > > > > Then will it be okay to rename current pinetab DT to >> > > > > pinetab-sample and then introduce new DTs all with suffixes? >> > > > >> > > > No. From my previous mail: >> > > >> > > It can be seen as dropping the PineTab DT and introduce new DTs >> > > with >> > > suffix. >> > > >> > > Do we have rule that we cannot drop boards? >> > >> > Are you really arguing that removing a DT and then adding an >> > identical >> > one under a different name is not renaming it? >> >> Then we can just keep confusing name? > >Sorry maybe I missed some information >But why don't you do like pinephone? They're the same board revision with different LCD panels. And the major problem is that the DT for samples is already submitted under the name "PineTab". >sun50i-a64-pinetab-1.0.dts >sun50i-a64-pinetab-1.1.dts > >-dev is also a confusing name I think, as the board has been already >shipped. > >Regards, >Clement > > >> >> If we do so, how can we mark the new DT as "the user should use this >> one"? >> >> -- >> You received this message because you are subscribed to the Google >Groups "linux-sunxi" group. >> To unsubscribe from this group and stop receiving emails from it, >send an email to linux-sunxi+unsubscr...@googlegroups.com. >> To view this discussion on the web, visit >https://groups.google.com/d/msgid/linux-sunxi/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/C8F86F90-14BF-4857-9DB8-7968A34E4656%40aosc.io.
Re: [linux-sunxi] [PATCH] sunxi: Add arm64 FEL support
在 2020-11-19星期四的 10:54 +，Andre Przywara写道： > So far we did not support the BootROM based FEL USB debug mode on the > 64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but > the > SPL runs in AArch64. > Returning back to AArch32 was not working as expected, since the RMR > reset into 32-bit mode always starts execution in the BootROM, but > not > in the FEL routine. > > After some debug and research and with help via IRC, the CPU hotplug > mechanism emerged as a solution: If a certain R_CPUCFG register > contains > some magic, the BootROM will immediately branch to an address stored > in > some other register. This works well for our purposes. > > Enable the FEL feature by providing early AArch32 code to first save > the > FEL state, *before* initially entering AArch64. > If we eventually determine that we should return to FEL, we reset > back > into AArch32, and use the CPU hotplug mechanism to run some small > AArch32 code snippet that restores the initially saved FEL state. > > That allows the normal AArch64 SPL build to be loaded via the sunxi- > fel > tool, with it returning into FEL mode, so that other payloads can be > transferred via FEL as well. > > Tested on A64, H5 and H6. > > Signed-off-by: Andre Przywara Tested-by: Icenowy Zheng > --- > arch/arm/cpu/armv8/Makefile | 2 + > arch/arm/cpu/armv8/fel_utils.S | 78 > + > arch/arm/include/asm/arch-sunxi/boot0.h | 14 + > include/configs/sunxi-common.h | 2 - > 4 files changed, 94 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/cpu/armv8/fel_utils.S > > diff --git a/arch/arm/cpu/armv8/Makefile > b/arch/arm/cpu/armv8/Makefile > index 93d26f98568..f7b4a5ee46c 100644 > --- a/arch/arm/cpu/armv8/Makefile > +++ b/arch/arm/cpu/armv8/Makefile > @@ -27,6 +27,8 @@ obj-$(CONFIG_ARM_SMCCC) += smccc-call.o > > ifndef CONFIG_SPL_BUILD > obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o spin_table_v8.o > +else > +obj-$(CONFIG_ARCH_SUNXI) += fel_utils.o > endif > obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o > sec_firmware_asm.o > > diff --git a/arch/arm/cpu/armv8/fel_utils.S > b/arch/arm/cpu/armv8/fel_utils.S > new file mode 100644 > index 000..334fdef7fa0 > --- /dev/null > +++ b/arch/arm/cpu/armv8/fel_utils.S > @@ -0,0 +1,78 @@ > +/* > + * Utility functions for FEL mode, when running SPL in AArch64. > + * > + * Copyright (c) 2017 Arm Ltd. > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include > +#include > +#include > +#include > + > +/* > + * We don't overwrite save_boot_params() here, to save the FEL state > upon > + * entry, since this would run *after* the RMR reset, which clobbers > that > + * state. > + * Instead we store the state _very_ early in the boot0 hook, > *before* > + * resetting to AArch64. > + */ > + > +/* > + * The FEL routines in BROM run in AArch32. > + * Reset back into 32-bit mode here and restore the saved FEL state > + * afterwards. > + * Resetting back into AArch32/EL3 using the RMR always enters the > BROM, > + * but we can use the CPU hotplug mechanism to branch back to our > code > + * immediately. > + */ > +ENTRY(return_to_fel) > + /* > + * the RMR reset will clear all registers, so save the > arguments > + * (LR and SP) in the fel_stash structure, which we read > anyways later > + */ > + adr x2, fel_stash > + str w0, [x2] > + str w1, [x2, #4] > + > + adr x1, fel_stash_addr // to find the fel_stash > address in AA32 > + str w2, [x1] > + > + ldr x0, =0xfa50392f // CPU hotplug magic > +#ifndef CONFIG_MACH_SUN50I_H6 > + ldr x2, =(SUNXI_CPUCFG_BASE + 0x1a4) // offset for CPU > hotplug base > + str w0, [x2, #0x8] > +#else > + ldr x2, =(SUNXI_RTC_BASE + 0x1b8) // > BOOT_CPU_HP_FLAG_REG > + str w0, [x2], #0x4 > +#endif > + adr x0, back_in_32 > + str w0, [x2] > + > + dsb sy > + isb sy > + mov x0, #2 // RMR reset into AArch32 > + dsb sy > + msr RMR_EL3, x0 > + isb sy > +1: wfi > + b 1b > + > +/* AArch32 code to restore the state from fel_stash and return back > to FEL. */ > +back_in_32: > + .word 0xe59f0028 // ldr r0, [pc, #40] ; load > fel_stash address > + .word 0xe5901008 // ldr r1, [r0, #8] > + .word 0xe129f001 // msr CPSR_fc, r1 > + .word 0xf57ff06f // isb > + .word 0xe590d000 // ldr
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道： > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: > > > > > > > Okay. But I'm not satisfied with a non-public sample > > > > > > > occupies > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a > > > > > > > pinetab-retail okay? > > > > > > > > > > > > To me, naming the production version anything but "pinetab" > > > > > > isn't > > > > > > satisfying either. > > > > > > > > > > I understand where you're coming from, but the point I was > > > > > making my > > > > > previous mail is precisely that it's not really possible. > > > > > > > > > > You want to name the early adopter version _the_ production > > > > > version. Let's assume the hardware changes again between the > > > > > early > > > > > adopter and mass-production version. Which one will be _the_ > > > > > production version? The early-adopter or the mass-produced > > > > > one? > > > > > > > > > > There's really no good answer here, and both would suck in > > > > > their > > > > > own way. The only way to deal with this is to simply avoid > > > > > defining one version as the one true board, and just loading > > > > > the > > > > > proper DT in u-boot based on whatever clue we have of the > > > > > hardware > > > > > revision. > > > > Then will it be okay to rename current pinetab DT to > > > > pinetab-sample and then introduce new DTs all with suffixes? > > > > > > No. From my previous mail: > > > > It can be seen as dropping the PineTab DT and introduce new DTs > > with > > suffix. > > > > Do we have rule that we cannot drop boards? > > Are you really arguing that removing a DT and then adding an > identical > one under a different name is not renaming it? Then we can just keep confusing name? If we do so, how can we mark the new DT as "the user should use this one"? -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io.
Re: [linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: v3s: enable EHCI/OHCI for Lichee Pi Zero
于 2020年11月28日 GMT+08:00 上午11:09:17, Chen-Yu Tsai 写到: >On Mon, Nov 23, 2020 at 6:22 PM Icenowy Zheng wrote: >> >> >> >> 于 2020年11月23日 GMT+08:00 上午11:37:43, Chen-Yu Tsai 写到: >> >On Sun, Nov 22, 2020 at 8:40 AM Icenowy Zheng >wrote: >> >> >> >> As the USB port on Lichee Pi Zero works in the OTG mode, enable >the >> >> EHCI/OHCI controllers for it. >> > >> >You should probably mention that the host controllers work better >> >than the OTG controller in host mode. Otherwise this change lacks >> >justification for enabling two extra hardware blocks. >> >> Our PHY driver do not sense whether ?HCI is enabled or not, so >> for host to work it's necessary to be enabled, otherwise the phy >> driver will just route USB to unenabled ?HCI and fail. > >So, this was never working in Linux to begin with? You should mention >that. Okay. > >Maybe a fixes tag is in order then. Well I can't judge whether this is necessary. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/4515AB80-D54A-41CF-A677-2109289E6138%40aosc.io.
[linux-sunxi] Re: [PATCH] ARM: dts: sun8i: s3: pinecube: add ethernet alias for Wi-Fi
在 2020-11-25星期三的 06:59 +0800，Icenowy Zheng写道：
> The PineCube board has a RTL8189ES Wi-Fi module on board, and the
> module
> doesn't have any MAC address programmed in.
Sorry, but now I'm unsure about this.
The module seems to have MAC address programmed.
>
> Add a ethernet alias in the DT, thus the bootloader will then be able
> to
> generate a MAC address into the device tree node of Wi-Fi.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/boot/dts/sun8i-s3-pinecube.dts | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
> b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
> index 4aa0ee897a0a..5086f713467a 100644
> --- a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
> +++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
> @@ -13,6 +13,7 @@ / {
> compatible = "pine64,pinecube", "sochip,s3", "allwinner,sun8i-
> v3";
>
> aliases {
> + ethernet0 = &rtl8189es;
> serial0 = &uart2;
> };
>
> @@ -156,6 +157,10 @@ &mmc1 {
> bus-width = <4>;
> non-removable;
> status = "okay";
> +
> + rtl8189es: wifi@1 {
> + reg = <1>;
> + };
> };
>
> &pio {
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/86cfbd41fe80b4936f20925aed0c9010806a0316.camel%40aosc.io.
[linux-sunxi] [PATCH] ARM: dts: sun8i: s3: pinecube: add ethernet alias for Wi-Fi
The PineCube board has a RTL8189ES Wi-Fi module on board, and the module
doesn't have any MAC address programmed in.
Add a ethernet alias in the DT, thus the bootloader will then be able to
generate a MAC address into the device tree node of Wi-Fi.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-s3-pinecube.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
index 4aa0ee897a0a..5086f713467a 100644
--- a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
+++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
@@ -13,6 +13,7 @@ / {
compatible = "pine64,pinecube", "sochip,s3", "allwinner,sun8i-v3";
aliases {
+ ethernet0 = &rtl8189es;
serial0 = &uart2;
};
@@ -156,6 +157,10 @@ &mmc1 {
bus-width = <4>;
non-removable;
status = "okay";
+
+ rtl8189es: wifi@1 {
+ reg = <1>;
+ };
};
&pio {
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201124225940.3750388-1-icenowy%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月23日 GMT+08:00 下午8:53:32, Maxime Ripard 写到:
>On Mon, Nov 23, 2020 at 07:25:47PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard
>写到:
>> >Hi!
>> >
>> >On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
>> >> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>> >> >>>>>>> +/ {
>> >> >>>>>>> + model = "PineTab Developer Sample";
>> >> >>>>>>> + compatible = "pine64,pinetab-dev",
>"allwinner,sun50i-a64";
>> >> >>>>>>> +};
>> >> >>>>>>
>> >> >>>>>> Changing the DT and the compatible half-way through it
>isn't
>> >ok. Please
>> >> >>>>>> add a new DT with the newer revision like we did for the
>> >pinephone
>> >> >>>>>
>> >> >>>>> We did this on Pine H64.
>> >> >>>>
>> >> >>>> What are you referring to? I couldn't find a commit where we
>did
>> >what
>> >> >>>> you suggested in that patch to the pine H64.
>> >> >>>
>> >> >>> Oh the situation is complex. On Pine H64, we didn't specify
>> >anything at
>> >> >>> start (which is the same here), the DT is originally
>> >version-neutral
>> >> >>> but then transitioned to model B, then reverted to model A.
>Here
>> >the DT is always
>> >> >>> for the sample.
>> >> >>>
>> >> >>> However, for Pine H64 there's model A/B names, but for PineTab
>> >there's no
>> >> >>> any samples that are sold, thus except who got the samples,
>all
>> >PineTab
>> >> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
>> >> >>
>> >> >> It's fairly simple really, we can't really predict the future,
>so
>> >any DT
>> >> >> submitted is for the current version of whatever board there
>is.
>> >This is
>> >>
>> >> I don't think that was the intention at all. The DT was submitted
>for
>> >a
>> >> future product, whatever that future product ends up being at the
>> >time
>> >> of its release. Since there are necessarily no users until the
>> >product
>> >> ships, there is no chance of breaking users by modifying the DT.
>> >
>> >There was no indication of that in the commit though
>> >
>> >> >> what we (somewhat messily) did for the PineH64, for the
>pinephone,
>> >or
>> >> >> really any other board that has several revisions
>> >>
>> >> Surely a non-public prototype doesn't count as a separate
>revision!
>> >This
>> >> sort of policy strongly discourages ever shipping a board with
>> >> out-of-the-box mainline Linux support. Because if there any
>hardware
>> >> bugs fixed between initial upstreaming and production, the
>> >manufacture
>> >> must come up with a new DT name.
>> >>
>> >> This is hostile to the users as well, because the "canonical" DT
>name
>> >no
>> >> longer matches the "canonical" (read: the only one ever available)
>> >> version of the hardware.
>> >>
>> >> Do you want manufacturers to submit their initial board DT as
>> >> "$BOARD-prototype.dts", just in case they have to make a change
>> >before
>> >> production? And only after the board is shipped (with out-of-tree
>> >> patches, of course, to use $BOARD.dts, since the shipped board is
>> >*not*
>> >> the prototype) submit a "$BOARD.dts" to mainline?
>> >>
>> >> Maxime, can you clarify specifically what the line is where a
>device
>> >> tree is "locked down" and further changes to the hardware require
>a
>> >new
>> >> name? First sample leaves the factory? $NUMBER units produced?
>First
>> >> sold to the public for money?
>> >
>> >The first board that is shipped to a user. From the wiki, the
>version
>> >supported here (I guess?) has been shipped to around 100 people, so
>it
>> >doesn't really qualify for the "non-public proto
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard 写到:
>Hi!
>
>On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
>> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>> >>>>>>> +/ {
>> >>>>>>> +model = "PineTab Developer Sample";
>> >>>>>>> +compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >>>>>>> +};
>> >>>>>>
>> >>>>>> Changing the DT and the compatible half-way through it isn't
>ok. Please
>> >>>>>> add a new DT with the newer revision like we did for the
>pinephone
>> >>>>>
>> >>>>> We did this on Pine H64.
>> >>>>
>> >>>> What are you referring to? I couldn't find a commit where we did
>what
>> >>>> you suggested in that patch to the pine H64.
>> >>>
>> >>> Oh the situation is complex. On Pine H64, we didn't specify
>anything at
>> >>> start (which is the same here), the DT is originally
>version-neutral
>> >>> but then transitioned to model B, then reverted to model A. Here
>the DT is always
>> >>> for the sample.
>> >>>
>> >>> However, for Pine H64 there's model A/B names, but for PineTab
>there's no
>> >>> any samples that are sold, thus except who got the samples, all
>PineTab
>> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
>> >>
>> >> It's fairly simple really, we can't really predict the future, so
>any DT
>> >> submitted is for the current version of whatever board there is.
>This is
>>
>> I don't think that was the intention at all. The DT was submitted for
>a
>> future product, whatever that future product ends up being at the
>time
>> of its release. Since there are necessarily no users until the
>product
>> ships, there is no chance of breaking users by modifying the DT.
>
>There was no indication of that in the commit though
>
>> >> what we (somewhat messily) did for the PineH64, for the pinephone,
>or
>> >> really any other board that has several revisions
>>
>> Surely a non-public prototype doesn't count as a separate revision!
>This
>> sort of policy strongly discourages ever shipping a board with
>> out-of-the-box mainline Linux support. Because if there any hardware
>> bugs fixed between initial upstreaming and production, the
>manufacture
>> must come up with a new DT name.
>>
>> This is hostile to the users as well, because the "canonical" DT name
>no
>> longer matches the "canonical" (read: the only one ever available)
>> version of the hardware.
>>
>> Do you want manufacturers to submit their initial board DT as
>> "$BOARD-prototype.dts", just in case they have to make a change
>before
>> production? And only after the board is shipped (with out-of-tree
>> patches, of course, to use $BOARD.dts, since the shipped board is
>*not*
>> the prototype) submit a "$BOARD.dts" to mainline?
>>
>> Maxime, can you clarify specifically what the line is where a device
>> tree is "locked down" and further changes to the hardware require a
>new
>> name? First sample leaves the factory? $NUMBER units produced? First
>> sold to the public for money?
>
>The first board that is shipped to a user. From the wiki, the version
>supported here (I guess?) has been shipped to around 100 people, so it
>doesn't really qualify for the "non-public prototype". We still have to
>support these users, whether we like it or not.
>
>> Without some guidance, or a change in policy, this problem is going
>to
>> keep coming up again and again.
>
>There's a few things that are interleaved here. First, there's two hard
>rules: never change the DT name and never change the compatible of a
>board.
>
>The former would break any build system, boot script or documentation,
>and the latter would break the DT compatibility.
>
>Aside from this, things get a bit blurrier since it's mostly about the
>intent. I'm fine with having a DT for a non-public prototype if it's
>clear from day one that it is. In this particular case, the DT just
>stated that support for the pinetab was added. I guess anyone would
>make
>the assumption without any context that this would be for the (or a)
>final design.
>
>Finally, I'd also
Re: [linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: v3s: enable EHCI/OHCI for Lichee Pi Zero
于 2020年11月23日 GMT+08:00 上午11:37:43, Chen-Yu Tsai 写到:
>On Sun, Nov 22, 2020 at 8:40 AM Icenowy Zheng wrote:
>>
>> As the USB port on Lichee Pi Zero works in the OTG mode, enable the
>> EHCI/OHCI controllers for it.
>
>You should probably mention that the host controllers work better
>than the OTG controller in host mode. Otherwise this change lacks
>justification for enabling two extra hardware blocks.
Our PHY driver do not sense whether ?HCI is enabled or not, so
for host to work it's necessary to be enabled, otherwise the phy
driver will just route USB to unenabled ?HCI and fail.
>
>ChenYu
>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> index 2e4587d26ce5..0cd969194acb 100644
>> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
>> @@ -77,6 +77,10 @@ red_led {
>> };
>> };
>>
>> +&ehci0 {
>> + status = "okay";
>> +};
>> +
>> &mmc0 {
>> broken-cd;
>> bus-width = <4>;
>> @@ -84,6 +88,10 @@ &mmc0 {
>> status = "okay";
>> };
>>
>> +&ohci0 {
>> + status = "okay";
>> +};
>> +
>> &uart0 {
>> pinctrl-0 = <&uart0_pb_pins>;
>> pinctrl-names = "default";
>> --
>> 2.28.0
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>https://groups.google.com/d/msgid/linux-sunxi/20201122004011.1957325-1-icenowy%40aosc.io.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/4FF2364F-76AE-4181-88BB-02AB95424DD4%40aosc.io.
[linux-sunxi] [PATCH 3/3] ARM: dts: sun8i: s3: switch PineCube to use OHCI/EHCI only
The PineCube board features a USB Type-A connector connected to the
SoC's USB pins.
As this is not designed for being used as a USB device, disable OTG
controller and route USB to OHCI/EHCI fixedly.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-s3-pinecube.dts | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
index 4aa0ee897a0a..c4177c54ef29 100644
--- a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
+++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
@@ -78,6 +78,12 @@ csi1_ep: endpoint {
};
};
+&ehci0 {
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ status = "okay";
+};
+
&emac {
phy-handle = <&int_mii_phy>;
phy-mode = "mii";
@@ -158,6 +164,12 @@ &mmc1 {
status = "okay";
};
+&ohci0 {
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ status = "okay";
+};
+
&pio {
vcc-pd-supply = <®_dcdc3>;
vcc-pe-supply = <®_ldo3>;
@@ -224,11 +236,6 @@ &uart2 {
status = "okay";
};
-&usb_otg {
- dr_mode = "host";
- status = "okay";
-};
-
&usbphy {
usb0_vbus-supply = <®_vcc5v0>;
status = "okay";
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201122004011.1957325-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH 2/3] ARM: dts: sun8i: v3s: enable EHCI/OHCI for Lichee Pi Zero
As the USB port on Lichee Pi Zero works in the OTG mode, enable the
EHCI/OHCI controllers for it.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 2e4587d26ce5..0cd969194acb 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -77,6 +77,10 @@ red_led {
};
};
+&ehci0 {
+ status = "okay";
+};
+
&mmc0 {
broken-cd;
bus-width = <4>;
@@ -84,6 +88,10 @@ &mmc0 {
status = "okay";
};
+&ohci0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-0 = <&uart0_pb_pins>;
pinctrl-names = "default";
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201122004011.1957325-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 1/3] ARM: dts: sun8i: v3s: add EHCI/OHCI0 device nodes
The USB PHY 0 on V3s SoC can also be routed to a pair of EHCI/OHCI
controllers.
Add the device nodes for the controllers.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7b2d684aeb97..3e7e99745b73 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -297,6 +297,25 @@ usbphy: phy@1c19400 {
#phy-cells = <1>;
};
+ ehci0: usb@1c1a000 {
+ compatible = "allwinner,sun8i-v3s-ehci", "generic-ehci";
+ reg = <0x01c1a000 0x100>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>;
+ resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
+ status = "disabled";
+ };
+
+ ohci0: usb@1c1a400 {
+ compatible = "allwinner,sun8i-v3s-ohci", "generic-ohci";
+ reg = <0x01c1a400 0x100>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>,
+<&ccu CLK_USB_OHCI0>;
+ resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
+ status = "disabled";
+ };
+
ccu: clock@1c2 {
compatible = "allwinner,sun8i-v3s-ccu";
reg = <0x01c2 0x400>;
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201122003841.1957034-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH 0/3] ARM: dts: sun8i: v3s: enable EHCI/OHCI
Formerly I forgot to add EHCI/OHCI0 device nodes to V3s DTs. This patchset adds them, and switches PineCube to use only OHCI/EHCI, not MUSB. Icenowy Zheng (3): ARM: dts: sun8i: v3s: add EHCI/OHCI0 device nodes ARM: dts: sun8i: v3s: enable EHCI/OHCI for Lichee Pi Zero ARM: dts: sun8i: s3: switch PineCube to use OHCI/EHCI only arch/arm/boot/dts/sun8i-s3-pinecube.dts | 17 - arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 8 arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++ 3 files changed, 39 insertions(+), 5 deletions(-) -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201122003841.1957034-1-icenowy%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月20日 GMT+08:00 下午11:59:39, Maxime Ripard 写到:
>On Tue, Nov 17, 2020 at 02:36:48AM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2020年11月16日 GMT+08:00 下午11:55:08, Maxime Ripard
>写到:
>> >On Tue, Nov 10, 2020 at 06:41:37PM +0800, Icenowy Zheng wrote:
>> >>
>> >>
>> >> 于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard
>
>> >写到:
>> >> >On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> >> >> Some developers received PineTab samples that used an old LCD
>> >panel.
>> >> >>
>> >> >> Add device tree for these samples.
>> >> >>
>> >> >> Signed-off-by: Icenowy Zheng
>> >> >> ---
>> >> >> arch/arm64/boot/dts/allwinner/Makefile| 1 +
>> >> >> .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28
>> >> >+++
>> >> >> 2 files changed, 29 insertions(+)
>> >> >> create mode 100644
>> >> >arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >>
>> >> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> index 211d1e9d4701..a221dcebfad4 100644
>> >> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>> >> >sun50i-a64-pinephone-1.0.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> >> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> >> >> diff --git
>> >a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >> new file mode 100644
>> >> >> index ..3a4153890f3e
>> >> >> --- /dev/null
>> >> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >> @@ -0,0 +1,28 @@
>> >> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> >> >> +/*
>> >> >> + * Copyright (C) 2020 Icenowy Zheng
>> >> >> + *
>> >> >> + */
>> >> >> +
>> >> >> +/dts-v1/;
>> >> >> +
>> >> >> +#include "sun50i-a64-pinetab.dts"
>> >> >> +
>> >> >> +/ {
>> >> >> + model = "PineTab Developer Sample";
>> >> >> + compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >> >> +};
>> >> >
>> >> >Changing the DT and the compatible half-way through it isn't ok.
>> >Please
>> >> >add a new DT with the newer revision like we did for the
>pinephone
>> >>
>> >> We did this on Pine H64.
>> >
>> >What are you referring to? I couldn't find a commit where we did
>what
>> >you suggested in that patch to the pine H64.
>>
>> Oh the situation is complex. On Pine H64, we didn't specify anything
>at
>> start (which is the same here), the DT is originally version-neutral
>> but then transitioned to model B, then reverted to model A. Here the
>DT is always
>> for the sample.
>>
>> However, for Pine H64 there's model A/B names, but for PineTab
>there's no
>> any samples that are sold, thus except who got the samples, all
>PineTab
>> owners simply owns a "PineTab", not a "PineTab xxx version".
>
>It's fairly simple really, we can't really predict the future, so any
>DT
>submitted is for the current version of whatever board there is. This
>is
>what we (somewhat messily) did for the PineH64, for the pinephone, or
>really any other board that has several revisions
Okay. But I'm not satisfied with a non-public sample occupies
the pinetab name. Is rename it to pinetab-dev and add a
pinetab-retail okay?
>
>Maxime
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/A8E91BA0-22FD-47F4-A5B2-A80A38FE9A0E%40aosc.io.
[linux-sunxi] [PATCH] ARM: dts: sun8i: v3s: fix GIC node memory range
Currently the GIC node in V3s DTSI follows some old DT examples, and
being broken. This leads a warning at boot.
Fix this.
Fixes: f989086ccbc6 ("ARM: dts: sunxi: add dtsi file for V3s SoC")
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7b2d684aeb97..f8f19d8fa795 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -545,7 +545,7 @@ csi1: camera@1cb4000 {
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
- <0x01c82000 0x1000>,
+ <0x01c82000 0x2000>,
<0x01c84000 0x2000>,
<0x01c86000 0x2000>;
interrupt-controller;
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201120050851.4123759-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH v3] sunxi: add PineCube board
PineCube is an IP camera development kit released by Pine64. It comes with the following compoents: - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC, a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps Ethernet port and FPC connectors for camera and daughter board. - An OV5640-based camera module which is connected to the parallel CSI bus of the mainboard. - A daughterboard with several buttons, a SD slot, some IR LEDs, a microphone and a speaker connector. As the device tree is synchronized in a previous commit, just add it to Makefile, create a new MAINTAINER item and provide a defconfig. Signed-off-by: Icenowy Zheng --- Changes since v2: - Add Makefile reference to DT. Changes since v1: - Dropped LDO3 quirk. arch/arm/dts/Makefile | 1 + board/sunxi/MAINTAINERS| 5 + configs/pinecube_defconfig | 15 +++ 3 files changed, 21 insertions(+) create mode 100644 configs/pinecube_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 7d1a369845..e6993733b0 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -587,6 +587,7 @@ dtb-$(CONFIG_MACH_SUN8I_R40) += \ sun8i-r40-bananapi-m2-ultra.dtb \ sun8i-v40-bananapi-m2-berry.dtb dtb-$(CONFIG_MACH_SUN8I_V3S) += \ + sun8i-s3-pinecube.dtb \ sun8i-v3s-licheepi-zero.dtb dtb-$(CONFIG_MACH_SUN50I_H5) += \ sun50i-h5-bananapi-m2-plus.dtb \ diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index d3755ae41a..735801ae1d 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -440,6 +440,11 @@ M: Vasily Khoruzhick S: Maintained F: configs/pinebook_defconfig +PINECUBE BOARD: +M: Icenowy Zheng +S: Maintained +F: configs/pinecube_defconfig + PINE64 BOARDS M: Andre Przywara S: Maintained diff --git a/configs/pinecube_defconfig b/configs/pinecube_defconfig new file mode 100644 index 00..a8c404f6b1 --- /dev/null +++ b/configs/pinecube_defconfig @@ -0,0 +1,15 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SPL=y +CONFIG_MACH_SUN8I_V3S=y +CONFIG_SUNXI_DRAM_DDR3_1333=y +CONFIG_DRAM_CLK=504 +CONFIG_DRAM_ODT_EN=y +CONFIG_I2C0_ENABLE=y +CONFIG_DEFAULT_DEVICE_TREE="sun8i-s3-pinecube" +CONFIG_SPL_I2C_SUPPORT=y +# CONFIG_NETDEVICES is not set +CONFIG_AXP209_POWER=y +CONFIG_AXP_DCDC2_VOLT=1250 +CONFIG_AXP_DCDC3_VOLT=3300 +CONFIG_CONS_INDEX=3 -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201118102717.635129-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH v2] sunxi: add PineCube board
PineCube is an IP camera development kit released by Pine64. It comes with the following compoents: - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC, a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps Ethernet port and FPC connectors for camera and daughter board. - An OV5640-based camera module which is connected to the parallel CSI bus of the mainboard. - A daughterboard with several buttons, a SD slot, some IR LEDs, a microphone and a speaker connector. As the device tree is synchronized in a previous commit, just add MAINTAINER item and a defconfig. Signed-off-by: Icenowy Zheng --- Changes in v2: - Removed LDO3 hack in U-Boot because LDO3 is kept disabled in U-Boot. board/sunxi/MAINTAINERS| 5 + configs/pinecube_defconfig | 15 +++ 2 files changed, 20 insertions(+) create mode 100644 configs/pinecube_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index d3755ae41a..735801ae1d 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -440,6 +440,11 @@ M: Vasily Khoruzhick S: Maintained F: configs/pinebook_defconfig +PINECUBE BOARD: +M: Icenowy Zheng +S: Maintained +F: configs/pinecube_defconfig + PINE64 BOARDS M: Andre Przywara S: Maintained diff --git a/configs/pinecube_defconfig b/configs/pinecube_defconfig new file mode 100644 index 00..a8c404f6b1 --- /dev/null +++ b/configs/pinecube_defconfig @@ -0,0 +1,15 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SPL=y +CONFIG_MACH_SUN8I_V3S=y +CONFIG_SUNXI_DRAM_DDR3_1333=y +CONFIG_DRAM_CLK=504 +CONFIG_DRAM_ODT_EN=y +CONFIG_I2C0_ENABLE=y +CONFIG_DEFAULT_DEVICE_TREE="sun8i-s3-pinecube" +CONFIG_SPL_I2C_SUPPORT=y +# CONFIG_NETDEVICES is not set +CONFIG_AXP209_POWER=y +CONFIG_AXP_DCDC2_VOLT=1250 +CONFIG_AXP_DCDC3_VOLT=3300 +CONFIG_CONS_INDEX=3 -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201118062927.581700-1-icenowy%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月16日 GMT+08:00 下午11:55:08, Maxime Ripard 写到:
>On Tue, Nov 10, 2020 at 06:41:37PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard
>写到:
>> >On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> >> Some developers received PineTab samples that used an old LCD
>panel.
>> >>
>> >> Add device tree for these samples.
>> >>
>> >> Signed-off-by: Icenowy Zheng
>> >> ---
>> >> arch/arm64/boot/dts/allwinner/Makefile| 1 +
>> >> .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28
>> >+++
>> >> 2 files changed, 29 insertions(+)
>> >> create mode 100644
>> >arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >>
>> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >b/arch/arm64/boot/dts/allwinner/Makefile
>> >> index 211d1e9d4701..a221dcebfad4 100644
>> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>> >sun50i-a64-pinephone-1.0.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> >> diff --git
>a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> new file mode 100644
>> >> index ..3a4153890f3e
>> >> --- /dev/null
>> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> @@ -0,0 +1,28 @@
>> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> >> +/*
>> >> + * Copyright (C) 2020 Icenowy Zheng
>> >> + *
>> >> + */
>> >> +
>> >> +/dts-v1/;
>> >> +
>> >> +#include "sun50i-a64-pinetab.dts"
>> >> +
>> >> +/ {
>> >> + model = "PineTab Developer Sample";
>> >> + compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >> +};
>> >
>> >Changing the DT and the compatible half-way through it isn't ok.
>Please
>> >add a new DT with the newer revision like we did for the pinephone
>>
>> We did this on Pine H64.
>
>What are you referring to? I couldn't find a commit where we did what
>you suggested in that patch to the pine H64.
Oh the situation is complex. On Pine H64, we didn't specify anything at
start (which is the same here), the DT is originally version-neutral
but then transitioned to model B, then reverted to model A. Here the DT is
always
for the sample.
However, for Pine H64 there's model A/B names, but for PineTab there's no
any samples that are sold, thus except who got the samples, all PineTab
owners simply owns a "PineTab", not a "PineTab xxx version".
>
>Maxime
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/8FFC1A6C-9CA4-4F94-91C4-F111A7519979%40aosc.io.
[linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard 写到:
>On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> Some developers received PineTab samples that used an old LCD panel.
>>
>> Add device tree for these samples.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm64/boot/dts/allwinner/Makefile| 1 +
>> .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28
>+++
>> 2 files changed, 29 insertions(+)
>> create mode 100644
>arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>b/arch/arm64/boot/dts/allwinner/Makefile
>> index 211d1e9d4701..a221dcebfad4 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>sun50i-a64-pinephone-1.0.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> new file mode 100644
>> index ..3a4153890f3e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> @@ -0,0 +1,28 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (C) 2020 Icenowy Zheng
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64-pinetab.dts"
>> +
>> +/ {
>> +model = "PineTab Developer Sample";
>> +compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> +};
>
>Changing the DT and the compatible half-way through it isn't ok. Please
>add a new DT with the newer revision like we did for the pinephone
We did this on Pine H64.
>
>Maxime
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/6175E674-E8BC-4199-8BE8-A983065C32D5%40aosc.io.
[linux-sunxi] [RFC PATCH 2/2] clk: sunxi-ng: a64: disable mux and pll notifiers for CPUX reclocking
After the dividers of PLL-CPUX disabled, there's no need for PLL-CPUX to
be gated when tweaking the clock of CPUX, thus reparenting CPUX to
osc24M is also now not needed.
Remove these notifiers.
Preventing reparenting CPUX is said to be able to help solving the issue
that the timer jumps backward according to Ondrej Jirman.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 6108d150a0e3..67d570efe5bd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -943,7 +943,6 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
struct resource *res;
void __iomem *reg;
u32 val;
- int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg = devm_ioremap_resource(&pdev->dev, res);
@@ -1029,18 +1028,7 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(val, reg + SUN50I_A64_CPUX_AXI_REG);
}
- ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun50i_a64_ccu_desc);
- if (ret)
- return ret;
-
- /* Gate then ungate PLL CPU after any rate changes */
- ccu_pll_notifier_register(&sun50i_a64_pll_cpu_nb);
-
- /* Reparent CPU during PLL CPU rate changes */
- ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
- &sun50i_a64_cpu_nb);
-
- return 0;
+ return sunxi_ccu_probe(pdev->dev.of_node, reg, &sun50i_a64_ccu_desc);
}
static const struct of_device_id sun50i_a64_ccu_ids[] = {
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201109053537.54450-1-icenowy%40aosc.io.
[linux-sunxi] [RFC PATCH 0/2] clk: sunxi-ng: a64: Remove CPUX mux switching
According to Ondrej Jirman, switching of the mux of CPUX clock is one of the sources of timer jumps on A64 (and maybe this will also lead to timer jump on H3). This patchset tries to remove this mux by disabling the dividers in PLL-CPUX. Both the lack of reparent when relocking and the prevention of PLL-CPUX dividers are behaviors of the BSP kernel. Icenowy Zheng (2): clk: sunxi-ng: a64: disable dividers in PLL-CPUX clk: sunxi-ng: a64: disable mux and pll notifiers for CPUX reclocking drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 93 ++- 1 file changed, 78 insertions(+), 15 deletions(-) -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201109053358.54220-1-icenowy%40aosc.io.
[linux-sunxi] [RFC PATCH 1/2] clk: sunxi-ng: a64: disable dividers in PLL-CPUX
According to the user manual, PLL-CPUX have two dividers, in which P is
only allowed when the desired rate is less than 240MHz. As the CCU
framework have no such feature yet and the clock rate that allows P is
much lower than where we normally operate, disallow the usage of P
factor now.
M is not restricted in the user manual, however according to the BSP PLL
setup table (see [1]), it's not used at all. To follow what the BSP
does, disable this factor too.
Disabling the dividers will make it possible to remove the need to
switch to osc24M when doing frequency scaling on PLL-CPUX.
In order to prevent boot-time usage of dividers (current known mainline
U-Boot implementation use m = 2), tweaking of the factors are done when
probing CCU driver.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 79 ++-
1 file changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 5f66bf879772..6108d150a0e3 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -23,13 +24,14 @@
#include "ccu-sun50i-a64.h"
+#define SUN50I_A64_PLL_CPUX_REG0x000
static struct ccu_nkmp pll_cpux_clk = {
.enable = BIT(31),
.lock = BIT(28),
.n = _SUNXI_CCU_MULT(8, 5),
.k = _SUNXI_CCU_MULT(4, 2),
- .m = _SUNXI_CCU_DIV(0, 2),
- .p = _SUNXI_CCU_DIV_MAX(16, 2, 4),
+ .m = _SUNXI_CCU_DIV_MAX(16, 2, 1),
+ .p = _SUNXI_CCU_DIV_MAX(0, 2, 1),
.common = {
.reg= 0x000,
.hw.init= CLK_HW_INIT("pll-cpux",
@@ -215,6 +217,7 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
BIT(28), /* lock */
CLK_SET_RATE_UNGATE);
+#define SUN50I_A64_CPUX_AXI_REG0x050
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpux", "pll-cpux" };
static SUNXI_CCU_MUX(cpux_clk, "cpux", cpux_parents,
@@ -954,6 +957,78 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
+ /* Disable any possible dividers on PLL-CPUX */
+ val = readl(reg + SUN50I_A64_PLL_CPUX_REG);
+ if (val & (GENMASK(17, 16) | GENMASK(1, 0))) {
+ unsigned int n, k, m, p;
+
+ n = ((val & GENMASK(12, 8)) >> 8) + 1;
+ k = ((val & GENMASK(5, 4)) >> 4) + 1;
+ m = (val & GENMASK(1, 0)) + 1;
+ p = 1 << ((val & GENMASK(17, 16)) >> 16);
+
+ /*
+* Known mainline U-Boot revisions never uses
+* divider p, and it will only use m when k = 3 or 4.
+* Specially judge for these cases, to satisfy
+* what will most possibly happen.
+* For m = 2 and k = 3, fractional change will be
+* applied to n, to mostly keep the clock rate.
+* For m = 2 and k = 4, just change to m = 1 and k = 2.
+* For other cases, just try to divide it from N.
+*/
+ if (p >= 2) {
+ n /= p;
+ p = 1;
+ }
+
+ if (m == 2) {
+ if (k == 3) {
+ k = 2;
+ n = n * 3 / 4;
+ m = 1;
+ }
+ if (k == 4) {
+ k = 2;
+ m = 1;
+ }
+ }
+
+ if (m >= 2) {
+ n /= m;
+ m = 1;
+ }
+
+ /* The user manual constrains n*k >= 10 */
+ if (n * k < 10) {
+ n = 10;
+ k = 1;
+ }
+
+ /* Switch CPUX clock to osc24M temporarily */
+ val = readl(reg + SUN50I_A64_CPUX_AXI_REG);
+ val &= ~GENMASK(17, 16);
+ val |= (1 << 16);
+ writel(val, reg + SUN50I_A64_CPUX_AXI_REG);
+ udelay(1);
+
+ /* Setup PLL-CPUX with new factors */
+ val = ((n - 1) << 8) | ((k - 1) << 4);
+ writel(val, reg + SUN50I_A64_PLL_CPUX_REG);
+ val |= BIT(31);
+ writel(val, reg + SUN50I_A64_PLL_CPUX_REG);
+ do {
+ /* Wait the PLL to lock */
+
[linux-sunxi] [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
Some developers received PineTab samples that used an old LCD panel.
Add device tree for these samples.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28 +++
2 files changed, 29 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..a221dcebfad4 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
new file mode 100644
index ..3a4153890f3e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+ model = "PineTab Developer Sample";
+ compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
+};
+
+&dsi {
+ /delete-node/ panel@0;
+
+ panel@0 {
+ compatible = "feixin,k101-im2ba02";
+ reg = <0>;
+ avdd-supply = <®_dc1sw>;
+ dvdd-supply = <®_dc1sw>;
+ cvdd-supply = <®_ldo_io1>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ backlight = <&backlight>;
+ };
+};
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201107125332.2223197-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 2/3] dt-bindings: arm: sunxi: add PineTab developer sample DT binding
Some developer samples of PineTab are distributed with the old and incompatible LCD panel. Add a device tree binding for this version of PineTab. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index ea07f57379d3..9cc5990dc311 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -682,6 +682,11 @@ properties: - const: pine64,pinetab - const: allwinner,sun50i-a64 + - description: Pine64 PineTab (Developer sample with the old LCD panel) +items: + - const: pine64,pinetab-dev + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201107125233.754-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 1/3] arm64: allwinner: dts: a64: pinetab: switch LCD panel to production one
All retail PineTabs use the new panel. Devices with the old panel are
only available to several developers as sample.
Switch the main PineTab DT to use the new panel, as it should reflect
what the retail device uses. Another DT for developers' sample will be
added later.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index 0494bfaf2ffa..d91a019301bf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -150,12 +150,10 @@ &dsi {
status = "okay";
panel@0 {
- compatible = "feixin,k101-im2ba02";
+ compatible = "feixin,k101-im2byl02";
reg = <0>;
- avdd-supply = <®_dc1sw>;
- dvdd-supply = <®_dc1sw>;
- cvdd-supply = <®_ldo_io1>;
- reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ power-supply = <®_dc1sw>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
backlight = <&backlight>;
};
};
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201107125043.367-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 0/3] Switch PineTab DT LCD panel to retail one
Retail PineTabs switched to K101-IM2BYL02 panel. This patchset tries to reflect this change, and add a DT for samples that still have K101-IM2BA02. Icenowy Zheng (3): arm64: allwinner: dts: a64: pinetab: switch LCD panel to production one dt-bindings: arm: sunxi: add PineTab developer sample DT binding arm64: allwinner: dts: a64: add DT for PineTab developer sample .../devicetree/bindings/arm/sunxi.yaml| 5 arch/arm64/boot/dts/allwinner/Makefile| 1 + .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28 +++ .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 8 ++ 4 files changed, 37 insertions(+), 5 deletions(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201107124958.253-1-icenowy%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 6/6] sunxi: add PineCube board
于 2020年10月27日 GMT+08:00 上午2:32:30, Maxime Ripard 写到: >On Mon, Oct 26, 2020 at 10:21:00PM +0800, Icenowy Zheng wrote: >> PineCube is an IP camera development kit released by Pine64. >> >> It comes with the following compoents: >> >> - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC, >> a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps >> Ethernet port and FPC connectors for camera and daughter board. >> - An OV5640-based camera module which is connected to the parallel >CSI >> bus of the mainboard. >> - A daughterboard with several buttons, a SD slot, some IR LEDs, a >> microphone and a speaker connector. >> >> As the device tree is synchronized in a previous commit, just add >> MAINTAINER item and a defconfig. >> >> Signed-off-by: Icenowy Zheng >> --- >> board/sunxi/MAINTAINERS| 5 + >> configs/pinecube_defconfig | 17 + >> 2 files changed, 22 insertions(+) >> create mode 100644 configs/pinecube_defconfig >> >> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS >> index 1180b86db3..5c53b2c878 100644 >> --- a/board/sunxi/MAINTAINERS >> +++ b/board/sunxi/MAINTAINERS >> @@ -440,6 +440,11 @@ M: Vasily Khoruzhick >> S: Maintained >> F: configs/pinebook_defconfig >> >> +PINECUBE BOARD: >> +M: Icenowy Zheng >> +S: Maintained >> +F: configs/pinecube_defconfig >> + >> PINE64 BOARDS >> M: Andre Przywara >> S: Maintained >> diff --git a/configs/pinecube_defconfig b/configs/pinecube_defconfig >> new file mode 100644 >> index 00..107562ee49 >> --- /dev/null >> +++ b/configs/pinecube_defconfig >> @@ -0,0 +1,17 @@ >> +CONFIG_ARM=y >> +CONFIG_ARCH_SUNXI=y >> +CONFIG_SPL=y >> +CONFIG_MACH_SUN8I_V3S=y >> +CONFIG_SUNXI_DRAM_DDR3_1333=y >> +CONFIG_DRAM_CLK=504 >> +CONFIG_DRAM_ODT_EN=y >> +CONFIG_I2C0_ENABLE=y >> +CONFIG_DEFAULT_DEVICE_TREE="sun8i-s3-pinecube" >> +CONFIG_SPL_I2C_SUPPORT=y >> +# CONFIG_NETDEVICES is not set >> +CONFIG_AXP209_POWER=y >> +CONFIG_AXP_DCDC2_VOLT=1250 >> +CONFIG_AXP_DCDC3_VOLT=3300 >> +CONFIG_AXP_ALDO3_VOLT_SLOPE_08=y >> +CONFIG_AXP_ALDO3_INRUSH_QUIRK=y > >It would be worth mentioning in the commit log why you need those >options. For the ALDO3 options, they might be not necessary in U-Boot stage, because it's finally only used in Linux stage. I don't know whether these are still needed when we declared the hack in DT for Linux. > >With that fixed, the whole series is >Acked-by: Maxime Ripard > >Thanks! >Maxime -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/877B7B36-CE6D-481A-AEAB-011E6C735F76%40aosc.io.
[linux-sunxi] [PATCH 6/6] sunxi: add PineCube board
PineCube is an IP camera development kit released by Pine64. It comes with the following compoents: - A mainboard with Sochip S3 SoC, a 16MByte SPI Flash, AXP209 PMIC, a power-only microUSB connector, a USB Type-A connector, a 10/100Mbps Ethernet port and FPC connectors for camera and daughter board. - An OV5640-based camera module which is connected to the parallel CSI bus of the mainboard. - A daughterboard with several buttons, a SD slot, some IR LEDs, a microphone and a speaker connector. As the device tree is synchronized in a previous commit, just add MAINTAINER item and a defconfig. Signed-off-by: Icenowy Zheng --- board/sunxi/MAINTAINERS| 5 + configs/pinecube_defconfig | 17 + 2 files changed, 22 insertions(+) create mode 100644 configs/pinecube_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 1180b86db3..5c53b2c878 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -440,6 +440,11 @@ M: Vasily Khoruzhick S: Maintained F: configs/pinebook_defconfig +PINECUBE BOARD: +M: Icenowy Zheng +S: Maintained +F: configs/pinecube_defconfig + PINE64 BOARDS M: Andre Przywara S: Maintained diff --git a/configs/pinecube_defconfig b/configs/pinecube_defconfig new file mode 100644 index 00..107562ee49 --- /dev/null +++ b/configs/pinecube_defconfig @@ -0,0 +1,17 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SPL=y +CONFIG_MACH_SUN8I_V3S=y +CONFIG_SUNXI_DRAM_DDR3_1333=y +CONFIG_DRAM_CLK=504 +CONFIG_DRAM_ODT_EN=y +CONFIG_I2C0_ENABLE=y +CONFIG_DEFAULT_DEVICE_TREE="sun8i-s3-pinecube" +CONFIG_SPL_I2C_SUPPORT=y +# CONFIG_NETDEVICES is not set +CONFIG_AXP209_POWER=y +CONFIG_AXP_DCDC2_VOLT=1250 +CONFIG_AXP_DCDC3_VOLT=3300 +CONFIG_AXP_ALDO3_VOLT_SLOPE_08=y +CONFIG_AXP_ALDO3_INRUSH_QUIRK=y +CONFIG_CONS_INDEX=3 -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201026142100.2945553-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 4/6] sunxi: allow to use AXP20[39] attached to I2C0 on V3 series
The reference design of Allwinner V3 series uses an
AXP203 or AXP209 PMIC attached to the I2C0 bus of the SoC, although the
first community-available V3s board, Lichee Pi Zero, omitted it.
Allow to introduce support for the PMIC on boards with it.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
board/sunxi/board.c| 4
drivers/power/Kconfig | 4 ++--
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index a646ea6a3c..f817d328f4 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -158,6 +158,7 @@ enum sunxi_gpio_number {
#define SUN5I_GPB_TWI1 2
#define SUN4I_GPB_TWI2 2
#define SUN5I_GPB_TWI2 2
+#define SUN8I_V3S_GPB_TWI0 2
#define SUN4I_GPB_UART02
#define SUN5I_GPB_UART02
#define SUN8I_GPB_UART22
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index a5cf0b65c7..3796213b9f 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -101,6 +101,10 @@ void i2c_init_board(void)
sunxi_gpio_set_cfgpin(SUNXI_GPH(14), SUN6I_GPH_TWI0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(15), SUN6I_GPH_TWI0);
clock_twi_onoff(0, 1);
+#elif defined(CONFIG_MACH_SUN8I_V3S)
+ sunxi_gpio_set_cfgpin(SUNXI_GPB(6), SUN8I_V3S_GPB_TWI0);
+ sunxi_gpio_set_cfgpin(SUNXI_GPB(7), SUN8I_V3S_GPB_TWI0);
+ clock_twi_onoff(0, 1);
#elif defined(CONFIG_MACH_SUN8I)
sunxi_gpio_set_cfgpin(SUNXI_GPH(2), SUN8I_GPH_TWI0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(3), SUN8I_GPH_TWI0);
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 5910926fac..02050f6f35 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -14,7 +14,7 @@ choice
default AXP209_POWER if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
default AXP221_POWER if MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33
|| MACH_SUN8I_R40
default AXP818_POWER if MACH_SUN8I_A83T
- default SUNXI_NO_PMIC if MACH_SUNXI_H3_H5 || MACH_SUN50I
+ default SUNXI_NO_PMIC if MACH_SUNXI_H3_H5 || MACH_SUN50I ||
MACH_SUN8I_V3S
config SUNXI_NO_PMIC
bool "board without a pmic"
@@ -32,7 +32,7 @@ config AXP152_POWER
config AXP209_POWER
bool "axp209 pmic support"
- depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
+ depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUN8I_V3S
select AXP_PMIC_BUS
select CMD_POWEROFF
---help---
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201026141936.2945268-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 5/6] sunxi: dts: sync Allwinner V3s-related DTs from Linux 5.10-rc1
This commit imports device tree files that are related to Allwinner V3
series from Linux commit 3650b228f83a ("Linux 5.10-rc1").
Signed-off-by: Icenowy Zheng
---
arch/arm/dts/sun8i-s3-lichee-zero-plus.dts| 53 +++
arch/arm/dts/sun8i-s3-pinecube.dts| 235 +
arch/arm/dts/sun8i-v3.dtsi| 27 ++
arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts | 96 ++
arch/arm/dts/sun8i-v3s-licheepi-zero.dts | 26 +-
arch/arm/dts/sun8i-v3s.dtsi | 318 --
6 files changed, 725 insertions(+), 30 deletions(-)
create mode 100644 arch/arm/dts/sun8i-s3-lichee-zero-plus.dts
create mode 100644 arch/arm/dts/sun8i-s3-pinecube.dts
create mode 100644 arch/arm/dts/sun8i-v3.dtsi
create mode 100644 arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts
diff --git a/arch/arm/dts/sun8i-s3-lichee-zero-plus.dts
b/arch/arm/dts/sun8i-s3-lichee-zero-plus.dts
new file mode 100644
index 00..d18192d51d
--- /dev/null
+++ b/arch/arm/dts/sun8i-s3-lichee-zero-plus.dts
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Icenowy Zheng
+ */
+
+/dts-v1/;
+#include "sun8i-v3.dtsi"
+
+#include
+
+/ {
+ model = "Sipeed Lichee Zero Plus";
+ compatible = "sipeed,lichee-zero-plus", "sochip,s3",
+"allwinner,sun8i-v3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+};
+
+&mmc0 {
+ broken-cd;
+ bus-width = <4>;
+ vmmc-supply = <®_vcc3v3>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-0 = <&uart0_pb_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "peripheral";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/sun8i-s3-pinecube.dts
b/arch/arm/dts/sun8i-s3-pinecube.dts
new file mode 100644
index 00..9bab6b7f40
--- /dev/null
+++ b/arch/arm/dts/sun8i-s3-pinecube.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright 2019 Icenowy Zheng
+ */
+
+/dts-v1/;
+#include "sun8i-v3.dtsi"
+#include
+#include
+
+/ {
+ model = "PineCube IP Camera";
+ compatible = "pine64,pinecube", "allwinner,sun8i-s3";
+
+ aliases {
+ serial0 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led1 {
+ label = "pine64:ir:led1";
+ gpios = <&pio 1 10 GPIO_ACTIVE_LOW>; /* PB10 */
+ };
+
+ led2 {
+ label = "pine64:ir:led2";
+ gpios = <&pio 1 12 GPIO_ACTIVE_LOW>; /* PB12 */
+ };
+ };
+
+ reg_vcc5v0: vcc5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_vcc_wifi: vcc-wifi {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-wifi";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&pio 1 2 GPIO_ACTIVE_LOW>; /* PB2 WIFI-EN */
+ vin-supply = <®_dcdc3>;
+ startup-delay-us = <20>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pio 1 3 GPIO_ACTIVE_LOW>; /* PB3 WIFI-RST */
+ post-power-on-delay-ms = <200>;
+ };
+};
+
+&csi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&csi1_8bit_pins>;
+ status = "okay";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_ep: endpoint {
+ remote-endpoint = <&ov5640_ep>;
+ bus-width = <8>;
+ hsync-active = <1>; /* Active high */
+ vsync-active = <0>; /* Active low */
+
[linux-sunxi] [PATCH 3/6] clk: sunxi: add compatible string for V3
A new compatible string is introduced for V3 CCU, because it has a few
extra features available.
Add the compatible string to the clock driver. As the extra features are
not touched, just share the description struct now.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi/clk_v3s.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/sunxi/clk_v3s.c b/drivers/clk/sunxi/clk_v3s.c
index b79446cc4f..f3fc06ab31 100644
--- a/drivers/clk/sunxi/clk_v3s.c
+++ b/drivers/clk/sunxi/clk_v3s.c
@@ -56,6 +56,8 @@ static int v3s_clk_bind(struct udevice *dev)
static const struct udevice_id v3s_clk_ids[] = {
{ .compatible = "allwinner,sun8i-v3s-ccu",
.data = (ulong)&v3s_ccu_desc },
+ { .compatible = "allwinner,sun8i-v3-ccu",
+ .data = (ulong)&v3s_ccu_desc },
{ }
};
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201026141805.2944823-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH 2/6] sunxi: gpio: introduce compatible string for V3 GPIO
A new compatible string is introduced for V3 GPIO, because it has more
pins available than V3s.
Add the compatible string to the GPIO driver.
Signed-off-by: Icenowy Zheng
---
drivers/gpio/sunxi_gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 3efccf496f..02c3471b56 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -351,6 +351,7 @@ static const struct udevice_id sunxi_gpio_ids[] = {
ID("allwinner,sun8i-a83t-pinctrl", a_all),
ID("allwinner,sun8i-h3-pinctrl",a_all),
ID("allwinner,sun8i-r40-pinctrl", a_all),
+ ID("allwinner,sun8i-v3-pinctrl",a_all),
ID("allwinner,sun8i-v3s-pinctrl", a_all),
ID("allwinner,sun9i-a80-pinctrl", a_all),
ID("allwinner,sun50i-a64-pinctrl", a_all),
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201026141805.2944823-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 1/6] sunxi: add V3/S3 support
Allwinner V3/Sochip S3 uses the same die with Allwinner V3s/S3L, but V3 comes with no co-packaged DDR (DDR3 is usually used externally), and S3L comes with co-packaged DDR3. Add support for Allwinner V3/S3 chips by add SoC names to original V3s choice, and allow to select DDR3. Signed-off-by: Icenowy Zheng --- arch/arm/mach-sunxi/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index be0822bfb7..31339ac2a1 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -253,7 +253,7 @@ config MACH_SUN8I_R40 select PHY_SUN4I_USB config MACH_SUN8I_V3S - bool "sun8i (Allwinner V3s)" + bool "sun8i (Allwinner V3/V3s/S3/S3L)" select CPU_V7A select CPU_V7_HAS_NONSEC select CPU_V7_HAS_VIRT @@ -363,7 +363,6 @@ choice config SUNXI_DRAM_DDR3_1333 bool "DDR3 1333" select SUNXI_DRAM_DDR3 - depends on !MACH_SUN8I_V3S ---help--- This option is the original only supported memory type, which suits many H3/H5/A64 boards available now. -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201026141604.2944417-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH 0/6] Allwinner V3/S3 support + PineCube support
This patchset tries to add support for Allwinner V3/S3 and Pine64 PineCube to U-Boot. First 3 patches adds support for Allwinner V3/S3 to U-Boot by expanding the code of V3s and add compatible strings to individual drivers. Then a patch allows V3 series chips to utilize the AXP20x driver in U-Boot. Finally the device tree is synchorized from Linux v5.10-rc1 (which contains the PineCube DT) and PineCube defconfig is added. Icenowy Zheng (6): sunxi: add V3/S3 support sunxi: gpio: introduce compatible string for V3 GPIO clk: sunxi: add compatible string for V3 sunxi: allow to use AXP20[39] attached to I2C0 on V3 series sunxi: dts: sync Allwinner V3s-related DTs from Linux 5.10-rc1 sunxi: add PineCube board arch/arm/dts/sun8i-s3-lichee-zero-plus.dts| 53 +++ arch/arm/dts/sun8i-s3-pinecube.dts| 235 + arch/arm/dts/sun8i-v3.dtsi| 27 ++ arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts | 96 ++ arch/arm/dts/sun8i-v3s-licheepi-zero.dts | 26 +- arch/arm/dts/sun8i-v3s.dtsi | 318 -- arch/arm/include/asm/arch-sunxi/gpio.h| 1 + arch/arm/mach-sunxi/Kconfig | 3 +- board/sunxi/MAINTAINERS | 5 + board/sunxi/board.c | 4 + configs/pinecube_defconfig| 17 + drivers/clk/sunxi/clk_v3s.c | 2 + drivers/gpio/sunxi_gpio.c | 1 + drivers/power/Kconfig | 4 +- 14 files changed, 758 insertions(+), 34 deletions(-) create mode 100644 arch/arm/dts/sun8i-s3-lichee-zero-plus.dts create mode 100644 arch/arm/dts/sun8i-s3-pinecube.dts create mode 100644 arch/arm/dts/sun8i-v3.dtsi create mode 100644 arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts create mode 100644 configs/pinecube_defconfig -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201026141604.2944417-1-icenowy%40aosc.io.
Re: [linux-sunxi] Re: [PATCH] net: phy: realtek: omit setting PHY-side delay when "rgmii" specified
于 2020年10月26日 GMT+08:00 上午1:28:48, Andrew Lunn 写到: >> >> 1. As the PHY chip has hardware configuration for configuring >delays, >> >> we should at least have a mode that respects what's set on the >> >hardware. >> > >> >Yes, that is PHY_INTERFACE_MODE_NA. In DT, set the phy-mode to "". >Or >> >for most MAC drivers, don't list a phy-mode at all. By referring to linux/phy.h, NA means not applicable. This surely do not apply when RGMII is really in use. >> >> However, we still need to tell the MAC it's RGMII mode that is in >use, not >> MII/RMII/*MII. So the phy-mode still needs to be something that >> contains rgmii. > >So for this MAC driver, you are going to have to fix the device tree. >And for the short turn, maybe implement the workaround discussed in >the other thread. I think no document declares RGMII must have all internal delays of the PHY explicitly disabled. It just says RGMII. I think the situation that RGMII is in use and PHY has the right to decide whether to add delay or not surely matches "rgmii", and to explicitly disable internal delays we need some other thing like "rgmii-noid". > >Andrew -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/C3279C11-EE7F-49FA-9BB3-ACA797B7B690%40aosc.io.
Re: [linux-sunxi] Re: [PATCH] net: phy: realtek: omit setting PHY-side delay when "rgmii" specified
于 2020年10月25日 GMT+08:00 下午10:36:08, Andrew Lunn 写到: >On Sun, Oct 25, 2020 at 10:27:05PM +0800, Icenowy Zheng wrote: >> >> >> 于 2020年10月25日 GMT+08:00 下午10:18:25, Andrew Lunn 写到: >> >On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote: >> >> Currently there are many boards that just set "rgmii" as phy-mode >in >> >the >> >> device tree, and leave the hardware [TR]XDLY pins to set PHY delay >> >mode. >> >> >> >> In order to keep old device tree working, omit setting delay for >just >> >> "RGMII" without any internal delay suffix, otherwise many devices >are >> >> broken. >> > >> >Hi Icenowy >> > >> >We have been here before with the Atheros PHY. It did not correctly >> >implement one of the delay modes, until somebody really did need >that >> >mode. So the driver was fixed. And we then found a number of device >> >trees were also buggy. It was painful for a while, but all the >device >> >trees got fixed. >> >> 1. As the PHY chip has hardware configuration for configuring delays, >> we should at least have a mode that respects what's set on the >hardware. > >Yes, that is PHY_INTERFACE_MODE_NA. In DT, set the phy-mode to "". Or >for most MAC drivers, don't list a phy-mode at all. However, we still need to tell the MAC it's RGMII mode that is in use, not MII/RMII/*MII. So the phy-mode still needs to be something that contains rgmii. > >> 2. As I know, at least Fedora ships a device tree with their >bootloader, and >> the DT will not be updated with kernel. > >I would check that. Debian does the exact opposite, the last time i >looked. It always uses the DT that come with the kernel because it >understands DT can have bugs, like all software. > > Andrew -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/F5D81295-B4CD-4B80-846A-39503B70E765%40aosc.io.
Re: [linux-sunxi] Re: [PATCH] net: phy: realtek: omit setting PHY-side delay when "rgmii" specified
于 2020年10月25日 GMT+08:00 下午10:18:25, Andrew Lunn 写到: >On Sun, Oct 25, 2020 at 04:55:56PM +0800, Icenowy Zheng wrote: >> Currently there are many boards that just set "rgmii" as phy-mode in >the >> device tree, and leave the hardware [TR]XDLY pins to set PHY delay >mode. >> >> In order to keep old device tree working, omit setting delay for just >> "RGMII" without any internal delay suffix, otherwise many devices are >> broken. > >Hi Icenowy > >We have been here before with the Atheros PHY. It did not correctly >implement one of the delay modes, until somebody really did need that >mode. So the driver was fixed. And we then found a number of device >trees were also buggy. It was painful for a while, but all the device >trees got fixed. 1. As the PHY chip has hardware configuration for configuring delays, we should at least have a mode that respects what's set on the hardware. 2. As I know, at least Fedora ships a device tree with their bootloader, and the DT will not be updated with kernel. This enforces compatibility with old DTs even if they're broken. Personally I think if someone wants a mode that explicitly disable delays in the PHY, a new mode may be created now, maybe called "rgmii-noid". > >We should do the same here. Please submit patches for the device tree >files. > > Andrew -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/77AAA8B8-2918-4646-BE47-910DDDE38371%40aosc.io.
[linux-sunxi] [PATCH] net: phy: realtek: omit setting PHY-side delay when "rgmii" specified
Currently there are many boards that just set "rgmii" as phy-mode in the
device tree, and leave the hardware [TR]XDLY pins to set PHY delay mode.
In order to keep old device tree working, omit setting delay for just
"RGMII" without any internal delay suffix, otherwise many devices are
broken.
The definition of "rgmii" in the DT binding document is "RX and TX
delays are added by MAC when required", which at least literally do not
forbid the PHY to add delays.
Fixes: bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
Signed-off-by: Icenowy Zheng
---
drivers/net/phy/realtek.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index fb1db713b7fb..7d32db1c789f 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -189,11 +189,6 @@ static int rtl8211f_config_init(struct phy_device *phydev)
phy_modify_paged_changed(phydev, 0xa43, RTL8211F_PHYCR1, val, val);
switch (phydev->interface) {
- case PHY_INTERFACE_MODE_RGMII:
- val_txdly = 0;
- val_rxdly = 0;
- break;
-
case PHY_INTERFACE_MODE_RGMII_RXID:
val_txdly = 0;
val_rxdly = RTL8211F_RX_DELAY;
@@ -253,9 +248,6 @@ static int rtl8211e_config_init(struct phy_device *phydev)
/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
switch (phydev->interface) {
- case PHY_INTERFACE_MODE_RGMII:
- val = RTL8211E_CTRL_DELAY | 0;
- break;
case PHY_INTERFACE_MODE_RGMII_ID:
val = RTL8211E_CTRL_DELAY | RTL8211E_TX_DELAY |
RTL8211E_RX_DELAY;
break;
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201025085556.2861021-1-icenowy%40aosc.io.
Re: [linux-sunxi] [PATCH 02/10] ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHY
于 2020年10月25日 GMT+08:00 上午2:30:35, "Jernej Škrabec"
写到:
>Dne sobota, 24. oktober 2020 ob 19:51:06 CEST je Icenowy Zheng
>napisal(a):
>> 在 2020-10-25星期日的 00:25 +0800，Chen-Yu Tsai写道：
>>
>> > From: Chen-Yu Tsai
>> >
>> > The Ethernet PHY on the A31 Hummingbird has the RX and TX delays
>> > enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins.
>> >
>> > Fix the phy-mode description to correct reflect this so that the
>> > implementation doesn't reconfigure the delays incorrectly. This
>> > happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
>> > rx/tx delay config").
>>
>> Personally I think they should revert this commit, and consider other
>> solution.
>>
>> This commit breaks everything.
>>
>
>Previously broken driver allowed inproper DT to work, so you have to
>fix
>everything eventually.
There is no "improper DT" if it's already shipped, DT should suffer driver
change, not changed to match driver.
I think at least Fedora tends to ship a DT with a system image that will
not get updated when kernel gets updated.
>
>Plus side, there is no need to have hack for Pine64 Plus ethernet
>anymore.
>
>Best regards,
>Jernej
>
>> (Although the patch on individual DT patches are technically correct)
>>
>> > Fixes: c220aec2bb79 ("ARM: dts: sun6i: Add Merrii A31 Hummingbird
>> > support")
>> > Signed-off-by: Chen-Yu Tsai
>> > ---
>> >
>> > arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> > b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> > index 049e6ab3cf56..73de34ae37fd 100644
>> > --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> > +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> > @@ -154,7 +154,7 @@ &gmac {
>> >
>> >pinctrl-names = "default";
>> >pinctrl-0 = <&gmac_rgmii_pins>;
>> >phy-handle = <&phy1>;
>> >
>> > - phy-mode = "rgmii";
>> > + phy-mode = "rgmii-id";
>> >
>> >status = "okay";
>> >
>> > };
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/9D317C52-5F28-41A9-80DA-DBADA142B042%40aosc.io.
Re: [linux-sunxi] [PATCH 02/10] ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHY
在 2020-10-25星期日的 00:25 +0800，Chen-Yu Tsai写道：
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the A31 Hummingbird has the RX and TX delays
> enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins.
>
> Fix the phy-mode description to correct reflect this so that the
> implementation doesn't reconfigure the delays incorrectly. This
> happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
> rx/tx delay config").
Personally I think they should revert this commit, and consider other
solution.
This commit breaks everything.
(Although the patch on individual DT patches are technically correct)
>
> Fixes: c220aec2bb79 ("ARM: dts: sun6i: Add Merrii A31 Hummingbird
> support")
> Signed-off-by: Chen-Yu Tsai
> ---
> arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> index 049e6ab3cf56..73de34ae37fd 100644
> --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> @@ -154,7 +154,7 @@ &gmac {
> pinctrl-names = "default";
> pinctrl-0 = <&gmac_rgmii_pins>;
> phy-handle = <&phy1>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> status = "okay";
> };
>
> --
> 2.28.0
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/79894e1266db69e463ee74a52551101298cae03e.camel%40aosc.io.
[linux-sunxi] [PATCH] sunxi: make V3s DRAM initialization more proper
Previously, because we have no source code about the DRAM initialization
of V3s and missing some configurations (delays and MBUS QoS info), our
V3s DRAM initialization sequence is hacked from the H3 one.
As the SDK shipped with PineCube contains source code for V3s libdram,
we can retrieve these information from it and tweak some other magic
bits.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/cpu.h | 1 +
arch/arm/mach-sunxi/dram_sunxi_dw.c | 91 +--
2 files changed, 87 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
b/arch/arm/include/asm/arch-sunxi/cpu.h
index 4c399b0a15..8b57d24e2f 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -16,6 +16,7 @@
#define SOCID_A64 0x1689
#define SOCID_H3 0x1680
+#define SOCID_V3S 0x1681
#define SOCID_H5 0x1718
#define SOCID_R40 0x1701
diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
b/arch/arm/mach-sunxi/dram_sunxi_dw.c
index a462538521..d0600011ff 100644
--- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
+++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
@@ -63,6 +63,8 @@ enum {
MBUS_PORT_CSI = 5,
MBUS_PORT_NAND = 6,
MBUS_PORT_SS= 7,
+ MBUS_PORT_DE_V3S= 8,
+ MBUS_PORT_DE_CFD_V3S= 9,
MBUS_PORT_TS= 8,
MBUS_PORT_DI= 9,
MBUS_PORT_DE= 10,
@@ -134,6 +136,29 @@ static void mctl_set_master_priority_h3(void)
MBUS_CONF(DE_CFD, true,HIGH, 0, 1024, 288, 64);
}
+static void mctl_set_master_priority_v3s(void)
+{
+ struct sunxi_mctl_com_reg * const mctl_com =
+ (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
+
+ /* enable bandwidth limit windows and set windows size 1us */
+ writel((1 << 16) | (400 << 0), &mctl_com->bwcr);
+
+ /* set cpu high priority */
+ writel(0x0001, &mctl_com->mapr);
+
+ MBUS_CONF( CPU, true, HIGHEST, 0, 160, 100, 80);
+ MBUS_CONF( GPU, true,HIGH, 0, 1792, 1536,0);
+ MBUS_CONF(UNUSED, true, HIGHEST, 0, 256, 128, 80);
+ MBUS_CONF( DMA, true,HIGH, 0, 256, 100,0);
+ MBUS_CONF(VE, true,HIGH, 0, 2048, 1600,0);
+ MBUS_CONF( CSI, true, HIGHEST, 0, 384, 256,0);
+ MBUS_CONF( NAND, true,HIGH, 0, 100, 50,0);
+ MBUS_CONF(SS, true,HIGH, 0, 384, 256,0);
+ MBUS_CONF(DE_V3S, false,HIGH, 0, 8192, 4096,0);
+ MBUS_CONF(DE_CFD_V3S, true,HIGH, 0, 640, 256,0);
+}
+
static void mctl_set_master_priority_a64(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
@@ -231,6 +256,9 @@ static void mctl_set_master_priority(uint16_t socid)
case SOCID_H3:
mctl_set_master_priority_h3();
return;
+ case SOCID_V3S:
+ mctl_set_master_priority_v3s();
+ return;
case SOCID_A64:
mctl_set_master_priority_a64();
return;
@@ -334,6 +362,28 @@ static void mctl_h3_zq_calibration_quirk(struct dram_para
*para)
}
}
+static void mctl_v3s_zq_calibration_quirk(struct dram_para *para)
+{
+ struct sunxi_mctl_ctl_reg * const mctl_ctl =
+ (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
+
+ u32 reg_val;
+
+ clrsetbits_le32(&mctl_ctl->zqcr, 0xff,
+ CONFIG_DRAM_ZQ & 0xff);
+ mctl_phy_init(PIR_ZCAL);
+
+ reg_val = readl(&mctl_ctl->zqdr[0]);
+ reg_val &= (0x1f << 16) | (0x1f << 0);
+ reg_val |= reg_val << 8;
+ writel(reg_val, &mctl_ctl->zqdr[0]);
+
+ reg_val = readl(&mctl_ctl->zqdr[1]);
+ reg_val &= (0x1f << 16) | (0x1f << 0);
+ reg_val |= reg_val << 8;
+ writel(reg_val, &mctl_ctl->zqdr[1]);
+}
+
static void mctl_set_cr(uint16_t socid, struct dram_para *para)
{
struct sunxi_mctl_com_reg * const mctl_com =
@@ -391,7 +441,7 @@ static void mctl_sys_init(uint16_t socid, struct dram_para
*para)
CCM_DRAMCLK_CFG_DIV(1) |
CCM_DRAMCLK_CFG_SRC_PLL11 |
CCM_DRAMCLK_CFG_UPD);
- } else if (socid == SOCID_H3 || socid == SOCID_H5) {
+ } else if (socid == SOCID_H3 || socid == SOCID_H5 || socid ==
SOCID_V3S) {
clock_set_pll5(CONFIG_DRAM_CLK * 2 * 100, false);
clrsetbits_le32(&ccm->dram_clk_cfg,
CCM_DRAMCLK_CFG_DIV_MASK |
@@ -474,6 +524,13 @@ static int mctl_channel_init(uint16_t socid, struct
dram_para *para)
/* dphy & aphy phase select 270 degree */
clrsetbits_le32(&mctl_ctl->pgcr
[linux-sunxi] [PATCH 2/2] dt-bindings: sram: sunxi-sram: add V3s compatible string
Add compatible string for V3s, with H3 one as fallback. This is used in device tree now, but not standardized in DT binding. Signed-off-by: Icenowy Zheng --- .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml index 6ebcbc153691..b66a07e21d1e 100644 --- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml +++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml @@ -33,6 +33,9 @@ properties: - const: allwinner,sun4i-a10-system-control - const: allwinner,sun8i-a23-system-control - const: allwinner,sun8i-h3-system-control + - items: + - const: allwinner,sun8i-v3s-system-control + - const: allwinner,sun8i-h3-system-control - items: - const: allwinner,sun8i-r40-system-control - const: allwinner,sun4i-a10-system-control -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201003235018.1121618-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH 1/2] ARM: dts: sun8i: s3: drop bogus cells for CSI subnode on PineCube
The address and size cells infomation in CSI subnode is not necessary
(because the camera subnode has no reg property).
Drop them.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-s3-pinecube.dts | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
index 9bab6b7f4014..76c8a29e355b 100644
--- a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
+++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
@@ -64,9 +64,6 @@ &csi1 {
status = "okay";
port {
- #address-cells = <1>;
- #size-cells = <0>;
-
csi1_ep: endpoint {
remote-endpoint = <&ov5640_ep>;
bus-width = <8>;
--
2.28.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20201003235018.1121618-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 0/2] Try to fix DT schema problems for V3-series DTs
This patchset tries to fix DT schema verification errors that exist in V3-series device trees. The first patch drops bogus properties that is not needed in PineCube DT, and the second one adds compatible to the binding. Icenowy Zheng (2): ARM: dts: sun8i: s3: drop bogus cells for CSI subnode on PineCube dt-bindings: sram: sunxi-sram: add V3s compatible string .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 3 +++ arch/arm/boot/dts/sun8i-s3-pinecube.dts| 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.28.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201003234842.1121077-1-icenowy%40aosc.io.
Re: [linux-sunxi] Re: [PATCH 0/7] Pine64 PineCube support
hema:
>/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:
>['allwinner,sun8i-v3s-system-control',
>'allwinner,sun8i-h3-system-control'] is not valid under any of the
>given schemas (Possible causes of the failure):
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible: Additional items are not allowed
>('allwinner,sun8i-h3-system-control' was unexpected)
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun4i-a10-sram-controller' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun4i-a10-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun5i-a13-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun7i-a20-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun8i-a23-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun8i-h3-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun8i-r40-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun50i-a64-sram-controller' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun50i-a64-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun50i-h5-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c00000: compatible:0:
>'allwinner,sun50i-h6-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,suniv-f1c100s-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:1:
>'allwinner,sun4i-a10-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:1:
>'allwinner,sun4i-a10-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:1:
>'allwinner,sun50i-a64-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:1:
>'allwinner,sun4i-a10-system-control' was expected
>
>Regards,
>Clement
>
>On Fri, 25 Sep 2020 at 17:12, Maxime Ripard wrote:
>>
>> Hi,
>>
>> On Wed, Sep 23, 2020 at 08:57:02AM +0800, Icenowy Zheng wrote:
>> > Pine64 PineCube is an IP camera based on Allwinner S3 chip.
>> >
>> > This patchset tries to add support for it.
>> >
>> > In order to make sure the system do not hang when camera is brought
>up,
>> > a fix to AXP209 driver is needed (sent individually), otherwise the
>> > system will hang because it changes the voltage of LDO2 when LDO4
>> > tweaking.
>>
>> Queued all the patches for 5.11
>>
>> > Icenowy Zheng (7):
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add Ethernet support
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for UART2 RX/TX
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add CSI1 device node
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for 8-bit parallel
>CSI
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for I2C1 at PE bank
>> > dt-bindings: arm: sunxi: add Pine64 PineCube binding
>> > ARM: dts: sun8i: s3l: add support for Pine64 PineCube IP camera
>>
>> However, I guess for the next patches to the v3s DTSI we should just
>> have a simpler prefix (like v3), it's really taking a lot of
>characters
>> here :)
>>
>> Maxime
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>https://groups.google.com/d/msgid/linux-sunxi/20200925151241.kfmytlff4grswtzh%40gilmour.lan.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/0BAFC9B7-DC42-469A-9C90-E25779678C07%40aosc.io.
[linux-sunxi] [PATCH 4/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for 8-bit parallel CSI
The CSI1 controller of V3/V3s/S3/S3L SoCs is used for parallel CSI.
As we're going to add support for Pine64 SCC board, which uses 8-bit
parallel CSI (and the MCLK output), add the pinctrl node of 8-bit
CSI and MCLK to the DTSI file.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 3e079973672d..19fba1a9115b 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -312,6 +312,20 @@ pio: pinctrl@1c20800 {
interrupt-controller;
#interrupt-cells = <3>;
+ /omit-if-no-ref/
+ csi1_8bit_pins: csi1-8bit-pins {
+ pins = "PE0", "PE2", "PE3", "PE8", "PE9",
+ "PE10", "PE11", "PE12", "PE13", "PE14",
+ "PE15";
+ function = "csi";
+ };
+
+ /omit-if-no-ref/
+ csi1_mclk_pin: csi1-mclk-pin {
+ pins = "PE1";
+ function = "csi";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PB6", "PB7";
function = "i2c0";
--
2.27.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200923010122.148661-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 7/7] ARM: dts: sun8i: s3l: add support for Pine64 PineCube IP camera
The Pine64 PineCube IP camera is an IP camera with SoChip S3 SoC.
It comes with a main board, an expansion board and a camera.
The main board features a Micro-USB power-only jack, a USB Type-A port,
an Ethernet port connected to the internal PHY of the SoC and a Realtek
RTL8189ES SDIO Wi-Fi module. A RGB LCD connector is reserved on the
board.
The expansion board features a TF slot, a microphone, a speaker
connector with on-board amplifier and a few IR LEDs.
Add support for the kit, with features on the main board and the
expansion board now.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-s3-pinecube.dts | 235
2 files changed, 236 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-s3-pinecube.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e7c59d0c8598..b163c8f1cefc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1198,6 +1198,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-r16-parrot.dtb \
sun8i-r40-bananapi-m2-ultra.dtb \
sun8i-s3-lichee-zero-plus.dtb \
+ sun8i-s3-pinecube.dtb \
sun8i-t3-cqa3t-bv3.dtb \
sun8i-v3s-licheepi-zero.dtb \
sun8i-v3s-licheepi-zero-dock.dtb \
diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
new file mode 100644
index ..9bab6b7f4014
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright 2019 Icenowy Zheng
+ */
+
+/dts-v1/;
+#include "sun8i-v3.dtsi"
+#include
+#include
+
+/ {
+ model = "PineCube IP Camera";
+ compatible = "pine64,pinecube", "allwinner,sun8i-s3";
+
+ aliases {
+ serial0 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led1 {
+ label = "pine64:ir:led1";
+ gpios = <&pio 1 10 GPIO_ACTIVE_LOW>; /* PB10 */
+ };
+
+ led2 {
+ label = "pine64:ir:led2";
+ gpios = <&pio 1 12 GPIO_ACTIVE_LOW>; /* PB12 */
+ };
+ };
+
+ reg_vcc5v0: vcc5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_vcc_wifi: vcc-wifi {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-wifi";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&pio 1 2 GPIO_ACTIVE_LOW>; /* PB2 WIFI-EN */
+ vin-supply = <®_dcdc3>;
+ startup-delay-us = <20>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pio 1 3 GPIO_ACTIVE_LOW>; /* PB3 WIFI-RST */
+ post-power-on-delay-ms = <200>;
+ };
+};
+
+&csi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&csi1_8bit_pins>;
+ status = "okay";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_ep: endpoint {
+ remote-endpoint = <&ov5640_ep>;
+ bus-width = <8>;
+ hsync-active = <1>; /* Active high */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp203",
+"x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&gic>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pe_pins>;
+ status = "okay";
+
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+
[linux-sunxi] [PATCH 5/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for I2C1 at PE bank
I2C1 controller is available at PE bank, usually used for
connecting an I2C-controlled camera sensor.
Add pinctrl node for it.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 19fba1a9115b..bae8fa9e356a 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -331,6 +331,12 @@ i2c0_pins: i2c0-pins {
function = "i2c0";
};
+ /omit-if-no-ref/
+ i2c1_pe_pins: i2c1-pe-pins {
+ pins = "PE21", "PE22";
+ function = "i2c1";
+ };
+
uart0_pb_pins: uart0-pb-pins {
pins = "PB8", "PB9";
function = "uart0";
--
2.27.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200923010014.148482-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH 6/7] dt-bindings: arm: sunxi: add Pine64 PineCube binding
Document board compatible names for Pine64 PineCube IP camera. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 5957a22c2e95..584b3fbf6e08 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -631,6 +631,11 @@ properties: - const: pine64,pine64-plus - const: allwinner,sun50i-a64 + - description: Pine64 PineCube +items: + - const: pine64,pinecube + - const: allwinner,sun8i-v3 + - description: Pine64 PineH64 model A items: - const: pine64,pine-h64 -- 2.27.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200923010215.148819-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 4/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for 8-bit parallel CSI
The CSI1 controller of V3/V3s/S3/S3L SoCs is used for parallel CSI.
As we're going to add support for Pine64 SCC board, which uses 8-bit
parallel CSI (and the MCLK output), add the pinctrl node of 8-bit
CSI and MCLK to the DTSI file.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 3e079973672d..19fba1a9115b 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -312,6 +312,20 @@ pio: pinctrl@1c20800 {
interrupt-controller;
#interrupt-cells = <3>;
+ /omit-if-no-ref/
+ csi1_8bit_pins: csi1-8bit-pins {
+ pins = "PE0", "PE2", "PE3", "PE8", "PE9",
+ "PE10", "PE11", "PE12", "PE13", "PE14",
+ "PE15";
+ function = "csi";
+ };
+
+ /omit-if-no-ref/
+ csi1_mclk_pin: csi1-mclk-pin {
+ pins = "PE1";
+ function = "csi";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PB6", "PB7";
function = "i2c0";
--
2.27.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200923010014.148482-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 2/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for UART2 RX/TX
The UART2 RX/TX pins on Allwinner V3 series is at PB0/1, which is used
as debugging UART on some boards.
Add pinctrl node for them.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7d40897dab09..4cfdf193cf88 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -322,6 +322,11 @@ uart0_pb_pins: uart0-pb-pins {
function = "uart0";
};
+ uart2_pins: uart2-pins {
+ pins = "PB0", "PB1";
+ function = "uart2";
+ };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2", "PF3",
"PF4", "PF5";
@@ -397,6 +402,8 @@ uart2: serial@1c28800 {
reg-io-width = <4>;
clocks = <&ccu CLK_BUS_UART2>;
resets = <&ccu RST_BUS_UART2>;
+ pinctrl-0 = <&uart2_pins>;
+ pinctrl-names = "default";
status = "disabled";
};
--
2.27.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200923005858.148261-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH 3/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add CSI1 device node
The CSI1 controller of V3/V3s/S3/S3L chips is used for parallel CSI.
Add the device tree node of it.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 4cfdf193cf88..3e079973672d 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -488,6 +488,18 @@ spi0: spi@1c68000 {
#size-cells = <0>;
};
+ csi1: camera@1cb4000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb4000 0x3000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
2.27.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200923005858.148261-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH 1/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add Ethernet support
The Allwinner V3/V3s/S3L/SoChip S3 Ethernet MAC and internal PHY is quite
similar to the ones on Allwinner H3, except for V3s the external MII is
not wired out.
Add ethernet support to V3/V3s/S3/S3L.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3.dtsi | 13
arch/arm/boot/dts/sun8i-v3s.dtsi | 52
2 files changed, 65 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3.dtsi b/arch/arm/boot/dts/sun8i-v3.dtsi
index 6ae8645ade50..ca4672ed2e02 100644
--- a/arch/arm/boot/dts/sun8i-v3.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3.dtsi
@@ -9,6 +9,19 @@ &ccu {
compatible = "allwinner,sun8i-v3-ccu";
};
+&emac {
+ /delete-property/ phy-handle;
+ /delete-property/ phy-mode;
+};
+
+&mdio_mux {
+ external_mdio: mdio@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
+
&pio {
compatible = "allwinner,sun8i-v3-pinctrl";
};
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 6eb9c39aa93f..7d40897dab09 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -138,6 +138,15 @@ mixer0_out_tcon0: endpoint {
};
};
+ syscon: system-control@1c0 {
+ compatible = "allwinner,sun8i-v3s-system-control",
+"allwinner,sun8i-h3-system-control";
+ reg = <0x01c0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+
tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun8i-v3s-tcon";
reg = <0x01c0c000 0x1000>;
@@ -415,6 +424,49 @@ i2c1: i2c@1c2b000 {
#size-cells = <0>;
};
+ emac: ethernet@1c3 {
+ compatible = "allwinner,sun8i-v3s-emac";
+ syscon = <&syscon>;
+ reg = <0x01c3 0x1>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ };
+
+ mdio_mux: mdio-mux {
+ compatible = "allwinner,sun8i-h3-mdio-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-parent-bus = <&mdio>;
+ /* Only one MDIO is usable at the time */
+ internal_mdio: mdio@1 {
+ compatible =
"allwinner,sun8i-h3-mdio-internal";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ int_mii_phy: ethernet-phy@1 {
+ compatible =
"ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+ };
+
spi0: spi@1c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.27.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200923005709.147966-2-icenowy%40aosc.io.
[linux-sunxi] [PATCH 0/7] Pine64 PineCube support
Pine64 PineCube is an IP camera based on Allwinner S3 chip. This patchset tries to add support for it. In order to make sure the system do not hang when camera is brought up, a fix to AXP209 driver is needed (sent individually), otherwise the system will hang because it changes the voltage of LDO2 when LDO4 tweaking. Icenowy Zheng (7): ARM: dts: sun8i: V3/V3s/S3/S3L: add Ethernet support ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for UART2 RX/TX ARM: dts: sun8i: V3/V3s/S3/S3L: add CSI1 device node ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for 8-bit parallel CSI ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for I2C1 at PE bank dt-bindings: arm: sunxi: add Pine64 PineCube binding ARM: dts: sun8i: s3l: add support for Pine64 PineCube IP camera .../devicetree/bindings/arm/sunxi.yaml| 5 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/sun8i-s3-pinecube.dts | 235 ++ arch/arm/boot/dts/sun8i-v3.dtsi | 13 + arch/arm/boot/dts/sun8i-v3s.dtsi | 91 +++ 5 files changed, 345 insertions(+) create mode 100644 arch/arm/boot/dts/sun8i-s3-pinecube.dts -- 2.27.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200923005709.147966-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH] regulator: axp20x: fix LDO2/4 description
Currently we wrongly set the mask of value of LDO2/4 both to the mask of
LDO2, and the LDO4 voltage configuration is left untouched. This leads
to conflict when LDO2/4 are both in use.
Fix this issue by setting different vsel_mask to both regulators.
Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
Signed-off-by: Icenowy Zheng
---
drivers/regulator/axp20x-regulator.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 1bacb37e8a99..cd1224182ad7 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -42,8 +42,9 @@
#define AXP20X_DCDC2_V_OUT_MASKGENMASK(5, 0)
#define AXP20X_DCDC3_V_OUT_MASKGENMASK(7, 0)
-#define AXP20X_LDO24_V_OUT_MASKGENMASK(7, 4)
+#define AXP20X_LDO2_V_OUT_MASK GENMASK(7, 4)
#define AXP20X_LDO3_V_OUT_MASK GENMASK(6, 0)
+#define AXP20X_LDO4_V_OUT_MASK GENMASK(3, 0)
#define AXP20X_LDO5_V_OUT_MASK GENMASK(7, 4)
#define AXP20X_PWR_OUT_EXTEN_MASK BIT_MASK(0)
@@ -542,14 +543,14 @@ static const struct regulator_desc axp20x_regulators[] = {
AXP20X_PWR_OUT_CTRL, AXP20X_PWR_OUT_DCDC3_MASK),
AXP_DESC_FIXED(AXP20X, LDO1, "ldo1", "acin", 1300),
AXP_DESC(AXP20X, LDO2, "ldo2", "ldo24in", 1800, 3300, 100,
-AXP20X_LDO24_V_OUT, AXP20X_LDO24_V_OUT_MASK,
+AXP20X_LDO24_V_OUT, AXP20X_LDO2_V_OUT_MASK,
AXP20X_PWR_OUT_CTRL, AXP20X_PWR_OUT_LDO2_MASK),
AXP_DESC(AXP20X, LDO3, "ldo3", "ldo3in", 700, 3500, 25,
AXP20X_LDO3_V_OUT, AXP20X_LDO3_V_OUT_MASK,
AXP20X_PWR_OUT_CTRL, AXP20X_PWR_OUT_LDO3_MASK),
AXP_DESC_RANGES(AXP20X, LDO4, "ldo4", "ldo24in",
axp20x_ldo4_ranges, AXP20X_LDO4_V_OUT_NUM_VOLTAGES,
- AXP20X_LDO24_V_OUT, AXP20X_LDO24_V_OUT_MASK,
+ AXP20X_LDO24_V_OUT, AXP20X_LDO4_V_OUT_MASK,
AXP20X_PWR_OUT_CTRL, AXP20X_PWR_OUT_LDO4_MASK),
AXP_DESC_IO(AXP20X, LDO5, "ldo5", "ldo5in", 1800, 3300, 100,
AXP20X_LDO5_V_OUT, AXP20X_LDO5_V_OUT_MASK,
--
2.27.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20200923005142.147135-1-icenowy%40aosc.io.
[linux-sunxi] [PATCH] ARM: add Kconfig option for PSCI 0.1
We still have some platforms that only implements functionalities in PSCI 0.1 (e.g. Allwinner ARMv7 SoCs). Add a Kconfig option for exporting only PSCI 0.1. The code to export PSCI 0.1 is still available and gets activated by this patch. In addition, default ARCH_SUNXI U-Boot PSCI implementation to export PSCI 0.1, to fix poweroff/reboot regression on Allwinner multi-core ARMv7 SoCs. Signed-off-by: Icenowy Zheng --- arch/arm/cpu/armv7/Kconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig index 8eee801dce..60bb0a9e1e 100644 --- a/arch/arm/cpu/armv7/Kconfig +++ b/arch/arm/cpu/armv7/Kconfig @@ -44,6 +44,7 @@ config ARMV7_PSCI choice prompt "Supported PSCI version" depends on ARMV7_PSCI + default ARMV7_PSCI_0_1 if ARCH_SUNXI default ARMV7_PSCI_1_0 help Select the supported PSCI version. @@ -53,6 +54,9 @@ config ARMV7_PSCI_1_0 config ARMV7_PSCI_0_2 bool "PSCI V0.2" + +config ARMV7_PSCI_0_1 + bool "PSCI V0.1" endchoice config ARMV7_PSCI_NR_CPUS -- 2.27.0 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200731185645.2106033-1-icenowy%40aosc.io.
