Re: [linux-sunxi] Help for 1-wire on Olimex's A64-OLinuXino-2Ge8G-IND: "pin already requested"

[Samuel Holland]

Hi Ilario,

On 10/10/23 08:57, Ilario Gelmetti wrote:
> Dear all,
> thanks for your work in supporting the Allwinner devices!!
> 
> I am trying to use the 1-wire instructions I found on the wiki here [1]
> for connecting some DS18B20 1-wire thermometer to an
> A64-OLinuXino-2Ge8G-IND [2]. This single board computer is running a
> Debian 11 Bullseye image prepared by the Olimex people [3] and currently
> I am running a 5.10.180-olimex kernel.
> 
> I understand that I have to create a DeviceTree overlay (that I never
> did before), load this overlay in the /boot/uEnv.txt file (that's the
> name on the OS I am using) and hope it works. Right?
> 
> My (failed) first attempt to write a DeviceTree overlay is described on
> the Olimex forums here [4], but I suspect this is the proper channel for
> asking for some help on this topic.
> 
> Following attempts also failed. I always got a "pin PB0 already
> requested by onewire_device; cannot claim for 1c20800.pinctrl:32" error.
> These attempts included writing the code directly in the kernel dtb file
> (decompiled and compiled with dtc and included in the /boot/kernel.itb
> command using mkimage -f kernel.its kernel.itb).
> 
> I copy and paste here the latest attempt of DeviceTree overlay here.
> 
> ```
> /dts-v1/;
> /plugin/;
> 
> / {
> compatible = "allwinner,sun50i-a64",
>  "olimex,a64-olinuxino";
> description = "Enable 1-Wire port";
> 
> fragment@0 {
>     target-path = "/";
>     __overlay__ {
>     onewire_device: onewire_device {
>     compatible = "w1-gpio";
>     gpios = < 1 0 0>; /* 1: B of PB0; 0: 0 of PB0; 0:
> GPIO_ACTIVE_HIGH */

You need GPIO_PULL_UP in the flags cell here.

>     pinctrl-names = "default";
>     pinctrl-0 = <_w1_pin>;
>     };
>     };
> };
> 
> fragment@1 {

And drop this entire fragment. See if it works with those two changes.

>     target = <>;
>  __overlay__ {
>     my_w1_pin: my_w1_pin@0 {
>     allwinner,pins = "PB0";
>     allwinner,function = "gpio_in";
>     allwinner,drive = <0>; /**/
>     allwinner,pull = <1>; /**/
>     };
>     };
> };
> };
> ```
> 
> I cannot get rid of this error in the dmesg (unless I specify two
> different pins in the two fragments, and then weird things happen, as
> explained in [4]):
> 
> [] Driver for 1-wire Dallas network protocol.
> [] sun50i-a64-pinctrl 1c20800.pinctrl: pin PB0 already requested by
> onewire_device; cannot claim for 1c20800.pinctrl:32
> [] sun50i-a64-pinctrl 1c20800.pinctrl: pin-32 (1c20800.pinctrl:32)
> status -22
> [] w1-gpio onewire_device: gpio_request (pin) failed
> [] w1-gpio: probe of onewire_device failed with error -22

The problem is that the GPIO reference and the pinctrl reference for the
same pin conflict. In this case, the only thing you need the pinctrl
reference for is the pull-up, which you can achieve with a GPIO flag.
However, for the more general case, you may need to apply some other
pinconf setting to a GPIO pin, so we may need to fix this.

Regards,
Samuel

> 
> Thanks for your help!!!
> Ilario
> 
> [1]: https://linux-sunxi.org/1-Wire
> [2]:
> https://www.olimex.com/Products/OLinuXino/A64/A64-OLinuXino/open-source-hardware
> [3]: https://images.olimex.com/
> [4]: https://www.olimex.com/forum/index.php?topic=9266.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/e6c916fd-014c-6c7a-7d81-bea833cc9060%40sholland.org.

Re: [linux-sunxi] Using the Linux Devicetrees for the D1

[Samuel Holland]

Hi Brandon,

On 10/23/23 05:45, Brandon Cheo Fusi wrote:
> Hi everyone,
> 
> After coming across this line 
> `Use the devicetree provided in RAM by the platform firmware (for
> U-Boot, this means $fdtcontroladdr). Do not load a DTB from storage`
> 
> at [1], and the discussion at [2], I've started to wonder what the use
> of devicetrees for D1 boards in Linux Mainline is. Why have them if one
> is restricted to only using U-Boot's devicetree ??

The devicetree source is maintained in the Linux repository because that
is where the binding documentation, schemas, and validation tools are.
The minor detail that there's also source code for an operating system
in that repository is irrelevant. The intention is to copy updates from
the Linux repository to the U-Boot repository after each stable release.
This ensures that the devicetrees exported by U-Boot will always conform
to a stable binding.

Regards,
Samuel

> Regards,
> Brandon.
> 
> [1] https://linux-sunxi.org/Allwinner_Nezha#Manual_build
> [2]
> https://lore.kernel.org/all/52217b50-c22f-5a21-e509-05d178e4a...@microchip.com/

-- 
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/ff66fde6-1711-e20f-0924-acef5d24eccc%40sholland.org.

[linux-sunxi] Re: [PATCH 5/8] sunxi: enable support for SPI NAND booting on SUNIV

[Samuel Holland]

On 10/13/22 22:05, Icenowy Zheng wrote:
> 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(-)

Reviewed-by: Samuel Holland 

> 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);

-- 
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/1019bbfc-2539-b899-d511-67fcfe0a044e%40sholland.org.

[linux-sunxi] Re: [PATCH 4/8] sunxi: SPL SPI: add initial support for booting from SPI NAND

[Samuel Holland]

On 10/13/22 22:05, Icenowy Zheng wrote:
> 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).

One warning generated when SPL_SPI_SUNXI_NAND is disabled. Otherwise, it
looks fine to me. I verified that NOR booting still works when
SPL_SPI_SUNXI_NAND is enabled, so:

Tested-by: Samuel Holland  # Orange Pi Zero Plus

> 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)
> +

[linux-sunxi] Re: [PATCH 3/8] sunxi: SPL SPI: allow multiple boot attempt

[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:

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_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_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/e071aa3b-8b3e-3b60-2403-48fab529ccb7%40sholland.org.

[linux-sunxi] Re: [PATCH 2/8] sunxi: SPL SPI: add support for read command with 2 byte address

[Samuel Holland]

On 10/13/22 22:05, Icenowy Zheng wrote:
> 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.

typo: big

> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/mach-sunxi/spl_spi_sunxi.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland  # Orange Pi Zero Plus

> 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();

-- 
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/8205834c-305b-cad8-fddd-f1183e467ce6%40sholland.org.

[linux-sunxi] Re: [PATCH 1/8] sunxi: SPL SPI: extract code for doing SPI transfer

[Samuel Holland]

On 10/13/22 22:05, Icenowy Zheng wrote:
> 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 

One comment below.

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland  # Orange Pi Zero Plus

> ---
>  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);

I think txbuf[i] would be a bit clearer here.

Regards,
Samuel

>  
>   /* 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 

Re: [linux-sunxi] How to enable 2 NAND chips on A33 SOC

[Samuel Holland]

Hi Mahmut,

On 10/25/22 07:53, Mahmut Dikçizgi wrote:
> I have noticed in sun8i-a23-a33.dtsi nand controller is only initialized
> with CS0 & RB0 pins, so DTB needs to report the kernel which pins to
> utilize to select chip1.
> 
> sun8i-a23-a33.dtsi:
>         nfc: nand-controller@1c03000 {
>             .
>             pinctrl-0 = <_pins *_cs0_pin _rb0_pin*>;
>             .
>         };
> Knowing that /master/drivers/mtd/nand/raw/sunxi_nand.c only uses 
> index to Chip select, and  index to detect busy, how can i
> tell kernel to use PC3 to CS1 & PC7 to RB1?

Since you are using the hardware CS and RB functions (not bit-banging),
those are the only possible choice of pins. All you need to do is select
function number 2 for these pins in the pinctrl.

> Since i am a DTS noob, i tried following in my board dts to override the
> dts and miserably failed:
> 
> pinctrl-names = "chip0pins", "chip1pins"; 
> pinctrl-0 = <_pins _cs0_pin _rb0_pin>;
> pinctrl-1 = <_pins _cs1_pin _rb1_pin>;
> both chips not detected
>
> pinctrl-0 = <_pins _cs0_pin _rb0_pin _pins
> _cs1_pin _rb1_pin>;
> both chips not detected

The "default" pinctrl name is actually important. Only the pinctrl-
entry with that name is applied during boot. So you need:

pinctrl-names = "default";
pinctrl-0 = <_pins _cs0_pin _rb0_pin
 _cs1_pin _rb1_pin>;

Where nand_cs1_pin and nand_rb1_pin reference PC3 and PC7 and the
"nand0" function.

Regards,
Samuel

-- 
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/0658d526-8041-958c-706e-5f3b165efd64%40sholland.org.

Re: [linux-sunxi] Kernel crash in "cpu_freq"

[Samuel Holland]

Hi Torsten,

On 7/19/22 3:44 AM, Torsten Beyer wrote:
> fantastic - I have built a kernel with changed setting yesterday afternoon
> (increased min OPP to 1.1V) and the system has been running for about 20hrs 
> now
> without freezes. Thanks for your help - looks like this patch fixes it. 

Thanks for the confirmation. The voltage regulator supplying the CPU (reg_dcdc2)
has a 25 mV step size, so you could see if a smaller change to the OPP is enough
to make the board stable.

I assume you are powering the board with a reasonably stable power supply? In
that case, it would be good to apply your change upstream, in case any other
Cubieboard 2 users are experiencing crashes. If you want to submit a patch, I
would suggest overriding the OPP table in the board-specific DTS. See here[1]
for an example of a board that does this.

Regards,
Samuel

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20-bananapi.dts#n105

-- 
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/dc03b197-492a-0979-728b-61d9135cb7d1%40sholland.org.

Re: [linux-sunxi] Kernel crash in "cpu_freq"

[Samuel Holland]

Hi Torsten,

On 7/18/22 7:13 AM, Torsten Beyer wrote:
> Hi again,
> 
> I believe I found the place. Can you confirm that changing the microvolts OPPs
> in "arch/arm/boot/dts/sun7i-a20.dtsi" is the right place for upping the
> microvolts for lower frequencies?

Yes, in that file, in the operating-points property of the cpu nodes.

Regards,
Samuel

-- 
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/02b404a3-8b1a-1da8-9048-3daba9e8166c%40sholland.org.

Re: [linux-sunxi] Kernel crash in "cpu_freq"

[Samuel Holland]

Hi Torsten,

On 7/13/22 3:18 AM, Torsten Beyer wrote:
> Hi all,
> 
> I am trying to debug a bug on an open source air navigation box for
> gliders called openvario . It is
> based on a cubieboard (A20) plus some additional serial connections
> and an optional sensor board for various flight related pressures.
> 
> System runs on kernel 5.18.5 generated using Yocto 4.0 kirkstone. The
> system tends to run for a couple of hours and then freezes/crashes.
> At the bottom of this post I have pasted a typical kernel debug
> output once these freezes happen. The crash always happens in the
> cpu_freq driver. If I set cpu frequency to a fixed frequency (setting
> min=max frequency) those crashed disappear. This seems to be a work
> around at the cost of fixing cpu speed.
> 
> So it _seems_ the crash is caused by cpu_freq trying to change the
> cpu frequency (at least at some point in time).
> 
> To be honest, I am rather clueless on how to go about finding the
> root of this issue, let along fixing it. So I thought, I'd ask around
> here whether this bug somehow looks familiar and may have been
> tackled (or even fixed) previously (didn't find anything, though, via
> the search function). In other words: I am thankful for any hint
> people may be able to give me to get nearer to a fix. 

I have not seen something like this before. It looks like hardware
flakiness. Can you provide a disassembly of ccu_div_recalc_rate
from the kernel this splat came from, to confirm my analysis?

> thanks for any pointers
> Torsten
> 
> [26996.004010] Unable to handle kernel paging request at virtual address 
> 08d80050
> [26996.011337] [08d80050] *pgd=
> [26996.014952] Internal error: Oops: 5 [#1] SMP ARM
> [26996.019590] Modules linked in:
> [26996.022663] CPU: 1 PID: 95 Comm: sugov:0 Not tainted 5.18.5 #1
> [26996.028509] Hardware name: Allwinner sun7i (A20) Family
> [26996.033738] PC is at ccu_div_recalc_rate+0x48/0x90
> [26996.038555] LR is at ccu_mux_helper_apply_prediv+0x18/0x1c

The crash is between the calls to ccu_mux_helper_apply_prediv and
divider_recalc_rate, so we are loading arguments for the call to
divider_recalc_rate.

> [26996.044054] pc : [] lr : [] psr: 600b0113
> [26996.050326] sp : f09e5dc8 ip :  fp : c1938200
> [26996.04] r10: c1867440 r9 : 1f78a400 r8 : c1302d00
> [26996.060781] r7 : 1312d000 r6 : 1f78a400 r5 : 0002 r4 : 08d80084

Assuming r4 is "hw", then the faulting address is cd->div.flags.
This is weird because r5 already contains cd->div.width...

> [26996.067311] r3 :  r2 :  r1 : 0001 r0 : 1f78a400

..and r3 already contains cd->div.table. So we were already able
to access parts of the struct both before and after the faulting
address.

> [26996.073843] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [26996.080985] Control: 10c5387d Table: 41ff006a DAC: 0051
> [26996.086733] Register r0 information: non-paged memory
> [26996.091799] Register r1 information: non-paged memory
> [26996.096858] Register r2 information: non-paged memory
> [26996.101915] Register r3 information: NULL pointer
> [26996.106627] Register r4 information: non-paged memory
> [26996.111688] Register r5 information: non-paged memory
> [26996.116746] Register r6 information: non-paged memory
> [26996.121805] Register r7 information: non-paged memory
> [26996.126863] Register r8 information: slab kmalloc-128 start c1302d00 
> pointer offset 0 size 128
> [26996.135514] Register r9 information: non-paged memory
> [26996.140574] Register r10 information: slab task_struct start c1867440 
> pointer offset 0
> [26996.148517] Register r11 information: slab kmalloc-128 start c1938200 
> pointer offset 0 size 128
> [26996.157244] Register r12 information: NULL pointer
> [26996.162049] Process sugov:0 (pid: 95, stack limit = 0xf4bf205c)
> [26996.167985] Stack: (0xf09e5dc8 to 0xf09e6000)
> [26996.172361] 5dc0:   c0d81584 c03db530  1f78a400 
> c1355700 c03d181c

What I think is happening is that the value in r4 got corrupted from
0xc0d81584 (the saved value on the top of the stack) to 0x08d80084.

Can you try increasing the voltage of the lower OPPs by 100 mV? And
if that doesn't work, try setting all of the OPPs to 1.4 V. That
should rule out any instability due to an insufficient CPU supply
voltage, and also due to any delay in slewing the regulator output.

Regards,
Samuel

> [26996.180547] 5de0: c1355600 c1355700 1f78a400 c03d34ec  c1355600 
> 1f78a400 39387000
> [26996.188733] 5e00: c1302d00 1f78a400 c1867440 c03d3554  c1302d00 
> 016e3600 39387000
> [26996.196917] 5e20: c1302d00 1f78a400 c1867440 c03d3554 c1355600  
> 1f78a400 c1867440
> [26996.205101] 5e40: c1302d00 1f78a400 c1867440 c03d39f0 1f78a400  
>  1f78a400
> [26996.213287] 5e60: c0d81bd0 df7bf617 c193a340 1f78a400 1f78a400 c1938300 
> ef7dc050 1f78a400
> [26996.221474] 5e80: c1867440 c03d3c28 c18b3b00 c1938500 1f78a400 

Re: [linux-sunxi] Trying to get samuels linux fork working on a D1 based board

[Samuel Holland]

Hi Hannes,

On 7/9/22 2:45 PM, Hannes Winkler wrote:
> Actually, I did replace the board.dtb with the `sun20i-d1-nezha.dtb` generated
> by your kernel build, so that should be fine, but yeah if the nezha dtb won't
> work on R01 anyway then that's probably why it didn't work

Ah, if you use a DTB from the kernel build, there is a different reason why it
would not work. Some information in the devicetree, such as the RAM size, is
automatically detected at runtime. That information is patched into the
devicetree by the firmware (SPL, OpenSBI, U-Boot) to tell Linux about it.

But that patching only happens to the devicetree that is built in to the
firmware package. If you load a DTB from extlinux.conf, it will not be patched,
and Linux will think the board has zero RAM. That causes the crash.

> Though I just found some the nezha board dts
> somewhere: 
> https://github.com/YuzukiHD/Buildroot-YuzukiSBC/blob/master/buildroot/board/awol/nezha-d1s/dts/linux/sun20i-d1s-nezha-linux.dts
> 
> So I could just diff it to the board.dts of the allwinner r01 linux and 
> roughly
> see what I need to change in your mainline forks' device tree right?

You could, assuming both downstream devicetrees were complete and accurate to
start with. It would still be more work than using the schematic.

>> Now that the R01 core board schematic has been released, I plan to do this 
>> in the next few days.
> 
> Thanks, appreciate your work!

Thank you!

Regards,
Samuel

-- 
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/f2f74f4d-31d0-3259-4aae-35e48ea0d5c5%40sholland.org.

Re: [linux-sunxi] Trying to get samuels linux fork working on a D1 based board

[Samuel Holland]

Hi Hannes,

On 7/9/22 6:30 AM, Hannes Winkler wrote:
> Hey all,
> 
> first of all I really appreciate all the work this community is doing to get
> allwinner hardware working with linux.
> 
> My hardware is a ClockworkPi Devterm R01:
> https://www.clockworkpi.com/product-page/devterm-kit-r01. The "official" linux
> is a 5.4 linux distro which is a slightly modified version of the official
> allwinner linux sources for that
> device: https://github.com/ardera/clockworkpi-r01-linux (linking my repo since
> it has the git history restored)
> 
> I'd like to boot Samuel Hollands linux fork on it, since the hardware seems to
> be very close to the Nezha board. So I just built his fork (`riscv/d1-wip`
> branch, with `nezha_defconfig`) and replaced the kernel on the official image
> with my custom-built kernel.
> 
> However, when booting, i get kernel panic pretty early on in the boot (see
> attachment).
> 
> I'm not that experienced with hw bringup so I'm a bit lost here. Is that just
> the kernel equivalent of a segfault? Could that mean something with the device
> tree is wrong? Could it be caused by an incompatible u-boot?

Yes, "Unable to handle kernel paging request" is effectively a kernel segfault.

Your first guess is most likely correct, that there is an issue with the
devicetree. I see from your log that you are loading "board.dtb", which I assume
came from the Allwinner BSP kernel build[1].

If my assumption is correct, that file is useless for booting mainline Linux.
Allwinner does not attempt to be compatible with the upstream devicetree
bindings/schema, or even with earlier versions of their own BSP. As a result,
"board.dtb" will only ever work with that one specific kernel.

What you need is a devicetree that follows the official/upstream schema. Then it
would be understood by both U-Boot and mainline Linux.

In fact, your U-Boot build already contains one of those, for the Nezha board.
If you remove the fdtfile line from your extlinux.conf file, that built-in
devicetree will get passed to Linux, and the system will probably boot. However,
I do *not* recommend this, because the R01 board has many differences from the
Nezha board, and using a devicetree for the wrong board could damage your 
hardware.

So someone will need to go through the schematic diagrams and write a devicetree
for the R01 core board and mainboard, using the upstream schema. Now that the
R01 core board schematic has been released, I plan to do this in the next few 
days.

Then you would build this new devicetree into U-Boot, and it would automatically
get provided to Linux.

Regards,
Samuel

[1]:
https://github.com/ardera/clockworkpi-r01-linux/blob/master/arch/riscv/boot/dts/sunxi/board.dts

-- 
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/ac9b675f-1496-e6e7-c68b-0fa53ae27e0f%40sholland.org.

Re: [linux-sunxi] u-boot: Wrong Image Format for bootm command

[Samuel Holland]

On 5/25/22 7:08 PM, Bram Stolk wrote:
> Thanks again, Samuel, for all your help.
> 
> Still not getting there:
> 
> => booti ${kernel_addr_r} ${ramdisk_addr_r}:0 ${fdt_addr_r}
> Moving Image from 0x4004 to 0x4020, end=415e10d8
> ERROR: Did not find a cmdline Flattened Device Tree
> Could not find a valid device tree
> 
> I will read up on "device trees" but I am not sure if I am responsible for
> setting that up before booting?

It is recommended to reuse the devicetree from U-Boot, which is already loaded
into RAM. Its address is stored in the predefined environment variable[1]
$fdtcontroladdr. Since it appears you don't have a ramdisk, you can try:

   booti ${kernel_addr_r} - ${fdtcontroladdr}

where the hyphen is a shortcut for "no ramdisk".

The devicetree at $fdtcontroladdr contains extra information detected by
firmware during boot, such as the size of RAM, which varies between boards. That
information would be missing, and Linux would fail to boot, if you loaded a DTB
file with "ext4load" or similar.

A generally simpler option may be to use an extlinux.conf file, since that hides
most of these details. The following example may be all you need:

# cat /boot/extlinux/extlinux.conf
label default
linux   ../Image
append  root=/dev/mmcblk0p2 rootwait
#

This will be loaded automatically if you mark your boot partition as bootable in
the partition table. Then you don't have to deal with environment variables,
booti vs. bootm, scripts, or devicetrees, etc.

Regards,
Samuel

[1]:
https://u-boot.readthedocs.io/en/latest/develop/devicetree/control.html?highlight=fdtcontroladdr#configuration

-- 
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/0f9e8601-bc90-e99d-6aa1-fd58dc27d223%40sholland.org.

Re: [linux-sunxi] u-boot: Wrong Image Format for bootm command

[Samuel Holland]

Hi Bram,

On 5/25/22 2:10 PM, Bram Stolk wrote:
> I have been following these instructions:
> https://linux-sunxi.org/Allwinner_Nezha#Mainline_kernel
> 
> But u-boot does not accept my kernel image.
> I tried both Image.gz and Image
> 
> => ext4load mmc 0:1 ${kernel_addr_r} Image
> 20515704 bytes read in 1906 ms (10.3 MiB/s)
> => bootm ${kernel_addr_r}
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!
> 
> The load command works fine. But when trying to boot it from memory, the 
> format
> is not accepted?

"bootm" expects the kernel to be wrapped in a U-Boot-specific header. To boot an
unmodified Linux "Image" file, you need to use the booti command[1].

There is a (rather non-obvious, I admit) note to this effect on the wiki[2],
which I just edited to note that it also applies to RISC-V.

Regards,
Samuel

[1]: https://u-boot.readthedocs.io/en/latest/usage/cmd/booti.html
[2]: https://linux-sunxi.org/U-Boot#Booting_with_boot.cmd

-- 
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/86b30b8b-ee46-e591-05ee-b790c9c2e69f%40sholland.org.

Re: [linux-sunxi] Debian on Sipeed Lichee RV86

[Samuel Holland]

On 5/24/22 7:45 PM, Bram Stolk wrote:
> Thanks.
> So I cloned https://github.com/smaeul/linux/commits/riscv/d1-wip
> 5.2GB... oof!
> 
> But it is not clear to me where I get a kernel configuration from?
> 
> Do I just use the src/linux/arch/riscv/configs/defconfig file?
> Does that one have everything the rv86 needs?

The top commit there adds arch/riscv/configs/nezha_defconfig, which has most if
not all of the relevant drivers enabled. So you can start with:

make ARCH=riscv nezha_defconfig

and adjust options from there. (This is by no means an "official" configuration.
It is just the one I happen to use for testing.)

Regards,
Samuel

> On Tue, May 24, 2022 at 4:35 PM Samuel Holland  <mailto:sam...@sholland.org>> wrote:
> 
> On 5/24/22 6:22 PM, Bram Stolk wrote:
> > Thanks. This is all very useful information.
> > I will attempt a build!
> > I take it that Ethernet does work with a mainline build?
> 
> Yes, Ethernet works fine on the mainline-based branch. The upstream 
> driver did
> not even need any changes for D1 support.
> 
> Regards,
> Samuel
> 
> > On Tue, May 24, 2022 at 10:52 AM Samuel Holland  <mailto:sam...@sholland.org>
> > <mailto:sam...@sholland.org <mailto:sam...@sholland.org>>> wrote:
> >
> >     Hi,
> >
> >     On 5/19/22 5:09 PM, Bram Stolk wrote:
> >     > Hi,
> >     >
> >     > I have a Sipeed Lichee RV86
> <https://linux-sunxi.org/Sipeed_Lichee_RV> panel.
> >     > It basically adds a screen/ethernet/wifi for the Lichee RV compute
> module
> >     (riscv64).
> >     >
> >     > I created an SDCARD using OpenixCard
> >     <https://github.com/YuzukiTsuru/OpenixCard>
> >     > tool and the manufacturer's image: *LicheeRV_Debian_86_480p.img*
> >     >
> >     > I'm pretty happy with the result. It's pretty nice to have a
> straightforward
> >     > linear framebuffer.
> >     > So I decided to remove all X11 stuff, and keep it as CLI with
> framebuffer.
> >     >
> >     >
> >     > Currently, I am trying to find out what is involved when I want to
> upgrade the
> >     > kernel.
> >
> >     You can upgrade to the mainline-based U-Boot and kernel by 
> following the
> >     instructions here:
> >
> >     https://linux-sunxi.org/Allwinner_Nezha#Manual_build
> >
> >     The only adjustment you need to make is selecting the right 
> devicetree
> for your
> >     board. You can do that by using `lichee_rv_86_panel_defconfig` 
> instead of
> >     `nezha_defconfig` when building U-Boot.
> >
> >     One thing to note is that mainline Linux does not yet support the 
> LCD
> panel used
> >     in the Sipeed Lichee RV 86 Panel. The display engine is supported, 
> and
> I ported
> >     over the panel driver, but for some reason it doesn't work, and I 
> have not
> >     debugged it. So if you switch now, you will lose your display 
> output.
> (Or this
> >     is an opportunity if you want to help get the panel working on 
> mainline.)
> >
> >     > I understand it uses U-BOOT.
> >     >
> >     > I am not sure where U-BOOT gets the kernel image from?
> >     >
> >     > mmcblk0     179:0    0   15G  0 disk
> >     > ├─mmcblk0p1 179:1    0  3.9M  0 part
> >     > ├─mmcblk0p2 179:2    0  252K  0 part
> >     > ├─mmcblk0p3 179:3    0  252K  0 part
> >     > ├─mmcblk0p4 179:4    0 10.1M  0 part
> >     > ├─mmcblk0p5 179:5    0  504K  0 part
> >     > ├─mmcblk0p6 179:6    0 13.8M  0 part
> >     > └─mmcblk0p7 179:7    0    8G  0 part /
> >     >
> >     > I don't see kernel images in the root filesystem.
> >
> >     Allwinner's downstream BSP U-Boot uses the Android boot flow, so one
> of those
> >     partitions is an Android boot.img (no filesystem, just the boot.img
> file written
> >     to the block device). Based on the partition sizes, I am guessing 
> that
> one or
> >     both of mmcblk0p4 or mmcblk0p6 are boot.img partitions.
> >
> >     Upstream U-Boot loads the kernel from a filesystem, as you would 
> expect.
> >
> >     > I am able to mount mmcblk0p1 but that fs just contains:
> >     > bootlogo.bm

Re: [linux-sunxi] Debian on Sipeed Lichee RV86

[Samuel Holland]

On 5/24/22 6:22 PM, Bram Stolk wrote:
> Thanks. This is all very useful information.
> I will attempt a build!
> I take it that Ethernet does work with a mainline build?

Yes, Ethernet works fine on the mainline-based branch. The upstream driver did
not even need any changes for D1 support.

Regards,
Samuel

> On Tue, May 24, 2022 at 10:52 AM Samuel Holland  <mailto:sam...@sholland.org>> wrote:
> 
> Hi,
> 
> On 5/19/22 5:09 PM, Bram Stolk wrote:
> > Hi,
> >
> > I have a Sipeed Lichee RV86 <https://linux-sunxi.org/Sipeed_Lichee_RV> 
> panel.
> > It basically adds a screen/ethernet/wifi for the Lichee RV compute 
> module
> (riscv64).
> >
> > I created an SDCARD using OpenixCard
> <https://github.com/YuzukiTsuru/OpenixCard>
> > tool and the manufacturer's image: *LicheeRV_Debian_86_480p.img*
> >
> > I'm pretty happy with the result. It's pretty nice to have a 
> straightforward
> > linear framebuffer.
> > So I decided to remove all X11 stuff, and keep it as CLI with 
> framebuffer.
> >
> >
> > Currently, I am trying to find out what is involved when I want to 
> upgrade the
> > kernel.
> 
> You can upgrade to the mainline-based U-Boot and kernel by following the
> instructions here:
> 
> https://linux-sunxi.org/Allwinner_Nezha#Manual_build
> 
> The only adjustment you need to make is selecting the right devicetree 
> for your
> board. You can do that by using `lichee_rv_86_panel_defconfig` instead of
> `nezha_defconfig` when building U-Boot.
> 
> One thing to note is that mainline Linux does not yet support the LCD 
> panel used
> in the Sipeed Lichee RV 86 Panel. The display engine is supported, and I 
> ported
> over the panel driver, but for some reason it doesn't work, and I have not
> debugged it. So if you switch now, you will lose your display output. (Or 
> this
> is an opportunity if you want to help get the panel working on mainline.)
> 
> > I understand it uses U-BOOT.
> >
> > I am not sure where U-BOOT gets the kernel image from?
> >
> > mmcblk0     179:0    0   15G  0 disk
> > ├─mmcblk0p1 179:1    0  3.9M  0 part
> > ├─mmcblk0p2 179:2    0  252K  0 part
> > ├─mmcblk0p3 179:3    0  252K  0 part
> > ├─mmcblk0p4 179:4    0 10.1M  0 part
> > ├─mmcblk0p5 179:5    0  504K  0 part
> > ├─mmcblk0p6 179:6    0 13.8M  0 part
> > └─mmcblk0p7 179:7    0    8G  0 part /
> >
> > I don't see kernel images in the root filesystem.
> 
> Allwinner's downstream BSP U-Boot uses the Android boot flow, so one of 
> those
> partitions is an Android boot.img (no filesystem, just the boot.img file 
> written
> to the block device). Based on the partition sizes, I am guessing that 
> one or
> both of mmcblk0p4 or mmcblk0p6 are boot.img partitions.
> 
> Upstream U-Boot loads the kernel from a filesystem, as you would expect.
> 
> > I am able to mount mmcblk0p1 but that fs just contains:
> > bootlogo.bmp
> > magic.bin
> >
> > Does the U-BOOT and kernel reside on the SOC maybe? Or is it on the 
> SDCARD
> as well?
> 
> U-Boot is on the SD card as well, at specific offsets/sector numbers from 
> the
> beginning of the card (sector 16, 256, 24576, or 32800). See the wiki 
> page for
> more explanation.
> 
> > I also tried holding down the "FEL" key when powering up to enter a
> "DOWNLOAD" mode.
> > When I do that, I indeed do not get boot output on the serial port. But
> nothing
> > else shows up on serial. I get no U-BOOT prompt, which I was expecting?
> 
> FEL mode is very minimal and does not itself touch the serial port. It 
> only
> communicates over USB. Generally, the way to use FEL is to use it to 
> download
> and execute U-Boot. Then you can interact with U-Boot over the serial 
> console.
> 
> Regards,
> Samuel
> 
> 
> 
> -- 
> Owner/Director of Game Studio Abraham Stolk Inc.
> Vancouver BC, Canada
> b.st...@gmail.com <mailto:b.st...@gmail.com>
> 

-- 
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/9395f3ef-7132-0f1d-277b-60b5b802cf73%40sholland.org.

Re: [linux-sunxi] Debian on Sipeed Lichee RV86

[Samuel Holland]

Hi,

On 5/19/22 5:09 PM, Bram Stolk wrote:
> Hi,
> 
> I have a Sipeed Lichee RV86  panel.
> It basically adds a screen/ethernet/wifi for the Lichee RV compute module 
> (riscv64).
> 
> I created an SDCARD using OpenixCard 
> 
> tool and the manufacturer's image: *LicheeRV_Debian_86_480p.img*
> 
> I'm pretty happy with the result. It's pretty nice to have a straightforward
> linear framebuffer.
> So I decided to remove all X11 stuff, and keep it as CLI with framebuffer.
> 
> 
> Currently, I am trying to find out what is involved when I want to upgrade the
> kernel.

You can upgrade to the mainline-based U-Boot and kernel by following the
instructions here:

https://linux-sunxi.org/Allwinner_Nezha#Manual_build

The only adjustment you need to make is selecting the right devicetree for your
board. You can do that by using `lichee_rv_86_panel_defconfig` instead of
`nezha_defconfig` when building U-Boot.

One thing to note is that mainline Linux does not yet support the LCD panel used
in the Sipeed Lichee RV 86 Panel. The display engine is supported, and I ported
over the panel driver, but for some reason it doesn't work, and I have not
debugged it. So if you switch now, you will lose your display output. (Or this
is an opportunity if you want to help get the panel working on mainline.)

> I understand it uses U-BOOT.
> 
> I am not sure where U-BOOT gets the kernel image from?
> 
> mmcblk0     179:0    0   15G  0 disk
> ├─mmcblk0p1 179:1    0  3.9M  0 part
> ├─mmcblk0p2 179:2    0  252K  0 part
> ├─mmcblk0p3 179:3    0  252K  0 part
> ├─mmcblk0p4 179:4    0 10.1M  0 part
> ├─mmcblk0p5 179:5    0  504K  0 part
> ├─mmcblk0p6 179:6    0 13.8M  0 part
> └─mmcblk0p7 179:7    0    8G  0 part /
> 
> I don't see kernel images in the root filesystem.

Allwinner's downstream BSP U-Boot uses the Android boot flow, so one of those
partitions is an Android boot.img (no filesystem, just the boot.img file written
to the block device). Based on the partition sizes, I am guessing that one or
both of mmcblk0p4 or mmcblk0p6 are boot.img partitions.

Upstream U-Boot loads the kernel from a filesystem, as you would expect.

> I am able to mount mmcblk0p1 but that fs just contains:
> bootlogo.bmp
> magic.bin
> 
> Does the U-BOOT and kernel reside on the SOC maybe? Or is it on the SDCARD as 
> well?

U-Boot is on the SD card as well, at specific offsets/sector numbers from the
beginning of the card (sector 16, 256, 24576, or 32800). See the wiki page for
more explanation.

> I also tried holding down the "FEL" key when powering up to enter a 
> "DOWNLOAD" mode.
> When I do that, I indeed do not get boot output on the serial port. But 
> nothing
> else shows up on serial. I get no U-BOOT prompt, which I was expecting?

FEL mode is very minimal and does not itself touch the serial port. It only
communicates over USB. Generally, the way to use FEL is to use it to download
and execute U-Boot. Then you can interact with U-Boot over the serial console.

Regards,
Samuel

-- 
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/0f89cb2e-0214-c0e1-2609-79cbb82f1c6d%40sholland.org.

[linux-sunxi] Re: [PATCH RESEND v3] arm64: dts: allwinner: a64: olinuxino: Enable audio

[Samuel Holland]

On 1/12/22 9:49 AM, Philip Rinn wrote:
> Enable the audio hardware on the Olimex A64-OLinuXino board family.
> Tested on the A64-OLinuXino-2Ge8G-IND variant.
> 
> Signed-off-by: Philip Rinn 
> ---
> 
> Changes in v2: added missing  {...} part
> Changes in v3: removed HDMI audio part as requested by Jernej Škrabec
> 
>  arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts| 30 
> +++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> index ec7e2c0e82c1..6f2674bb1b7f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> @@ -58,6 +58,15 @@ wifi_pwrseq: wifi_pwrseq {
>   };
>  };
>  
> + {
> + status = "okay";
> +};
> +
> +_analog {
> + cpvdd-supply = <_eldo1>;
> + status = "okay";
> +};
> +
>   {
>   cpu-supply = <_dcdc2>;
>  };
> @@ -74,6 +83,10 @@  {
>   cpu-supply = <_dcdc2>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>  };
> @@ -328,6 +341,23 @@ _hdmi {
>   vcc-hdmi-supply = <_dldo1>;
>  };
>  
> + {
> + simple-audio-card,aux-devs = <_analog>;
> + simple-audio-card,widgets = "Microphone", "Microphone Jack Left",
> + "Microphone", "Microphone Jack Right",
> + "Headphone", "Headphone Jack";
> + simple-audio-card,routing = "Left DAC", "DACL",
> + "Right DAC", "DACR",
> + "Headphone Jack", "HP",
> + "ADCL", "Left ADC",
> + "ADCR", "Right ADC",
> + "Microphone Jack Left", "MBIAS",
> + "MIC1", "Microphone Jack Left",
> + "Microphone Jack Left", "HBIAS",

According to the schematic, both sides of the microphone jack are biased to
MBIAS. Otherwise, this patch looks good to me.

Regards,
Samuel

> + "MIC2", "Microphone Jack Right";
> + status = "okay";
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pb_pins>;
> 

-- 
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/4fc41278-c46c-6486-a336-f2a329bd6bd0%40sholland.org.

Re: [linux-sunxi] Re: A20 Board with Audio Amplifier

[Samuel Holland]

Hello,

On 3/25/22 10:18 AM, Daft Soft wrote:
> Hi!
> Is FEX-file applicable on 5.x kernel?

No, mainline Linux describes the audio routing in the device tree, not via FEX.

> On Monday, 7 March 2022 at 13:25:27 UTC+3 mullappil...@gmail.com wrote:
> 
> i have a board with A20 and  PAM8620 audio amplifier. 3.4 kernel works 
> with
> good audio along with patches on sunxi-codec.c, now moved to kernel 5.16,
> and audio is not working.
> the fex file has following entry
> 
> [audio_para]
> audio_used = 1
> audio_pa_ctrl = port:PH15<1><0>
> audio_mute_ctrl = port:PH25<1><0>
> 
> any help is appreciated

Normally, external amplifiers use the "simple-audio-amplifier" binding here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml

The amplifier node is an "auxiliary device" referenced from the sound card via
an "aux-devs" property, and the amplifier DAPM widgets (INL, INR, OUTL, OUTR)
are added to the "allwinner,audio-routing" property.

This setup with an external amplifier is common on A64 boards, for example:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi?h=v5.17#n436

The problem with the A20 codec is that the mainline driver does not currently
support an "aux-devs" property. You would need to add a call from
sun4i_codec_create_card() to something like:

snd_soc_of_parse_aux_devs(card, "allwinner,aux-devs");

Then you could use the binding I described above.

Regards,
Samuel

-- 
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/0acdc596-e381-5fd2-0bd2-b0aa7990ddc6%40sholland.org.

[linux-sunxi] Re: [PATCH v9 08/11] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Samuel Holland]

Hi Andre,

I took another look at this while working on the RTC binding.

On 8/1/21 7:39 PM, 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).
> And while there is still the extra sunxi interrupt controller, the
> package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> 
> The reserved memory node is actually handled by Trusted Firmware now,
> but U-Boot fails to propagate this to a separately loaded DTB, so we
> keep it in here for now, until U-Boot learns to do this properly.
> 
> Signed-off-by: Andre Przywara 
> ---
>  .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 575 ++
>  1 file changed, 575 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 ..6a15ff2e7ebf
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -0,0 +1,575 @@
> +// 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 = <>;
> + #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 = < CLK_CPUX>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + clocks = < CLK_CPUX>;
> + };
> +
> + cpu2: cpu@2 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + clocks = < CLK_CPUX>;
> + };
> +
> + cpu3: cpu@3 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + clocks = < 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;
> + };
> + };
> +
> + 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 = <>, <>, <>, <>;
> + };
> +
> + 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)>,
> +   + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + soc@0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x4000>;
> +
> + syscon: syscon@300 {
> + compatible = "allwinner,sun50i-h616-system-control";
> + reg = <0x0300 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram_c: sram@28000 {
> + compatible = "mmio-sram";
> + reg = <0x00028000 0x3>;
> + #address-cells = <1>;
> + 

[linux-sunxi] Re: [PATCH v8 02/11] dt-bindings: rtc: sun6i: Add H616 compatible string

[Samuel Holland]

On 8/18/21 4:04 AM, Andre Przywara wrote:
> On Tue, 17 Aug 2021 09:38:10 +0200
> Maxime Ripard  wrote:
> 
> Hi Maxime,
> 
>> On Mon, Aug 02, 2021 at 01:39:38AM +0100, Andre Przywara wrote:
>>> On Mon, 26 Jul 2021 16:41:37 +0200
>>> Maxime Ripard  wrote:
>>>   
 Hi,

 On Fri, Jul 23, 2021 at 04:38:29PM +0100, Andre Przywara wrote:  
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> Also the clock part is quite different, as there is no external 32K LOSC
> oscillator input.
>
> Signed-off-by: Andre Przywara 
>
> ---
>  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml  | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> index beeb90e55727..d8a6500e5840 100644
> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> @@ -26,6 +26,7 @@ properties:
>- const: allwinner,sun50i-a64-rtc
>- const: allwinner,sun8i-h3-rtc
>- const: allwinner,sun50i-h6-rtc
> +  - const: allwinner,sun50i-h616-rtc
>  
>reg:
>  maxItems: 1
> @@ -104,6 +105,19 @@ allOf:
>minItems: 3
>maxItems: 3
>  
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: allwinner,sun50i-h616-rtc
> +
> +then:
> +  properties:
> +clock-output-names:
> +  minItems: 3
> +  maxItems: 3

 You don't need both of them when they are equal
   
> +clocks: false
> +

 It's not entirely clear to me what those clocks are about though. If we
 look at the clock output in the user manual, it looks like there's only
 two clocks that are actually being output: the 32k "fanout" clock and
 the losc. What are the 3 you're talking about?]  
>>>
>>> I see three: the raw SYSTEM "CLK32K_LOSC", the RTC input + debounce
>>> clock (/32), and the multiplexed PAD.  
>>
>> But the input and debounce clock is only for the RTC itself right? So it
>> should be local to the driver and doesn't need to be made available to
>> the other drivers
> 
> I understood "debounce" as being the clock used for the pinctrl
> debouncer. What would it debounce otherwise? Do you think that this
> "debounce circuit" is something internal to the RTC and is totally
> irrelevant for us?

I'm pretty sure this is the debounce for the NMI and the SoC reset signal, not
the pinctrl. The pinctrl debounce clock pretty clearly references 32 kHz.

> But in general I looked at how many *different* clocks this diagram
> describes, and I count: one unaltered ("SYSTEM"), one "div by
> 32" (RTC/debounce), and one multiplexed. My aim was to avoid
> DT binding changes when we later discover we do need one of them for
> something (as happened in the past). So three seemed to be the safe
> choice here, to avoid surprises. In the worst case we just will never
> reference one of them.

Plus RC16M/IOSC (and depending on how you look at it, DCXO24M/HOSC).

>> Either way, what this list is must be documented.
> 
> You mean to overwrite the "description" stanza for clock-output-names?
> And can this be done in the per-SoC parts in the later part of the
> binding, keeping the existing description?
> 
> Cheers,
> Andre
> 
>>
 Also, it looks like the 32k fanout clock needs at least the hosc or
 pll-periph in input, so we probably don't want to ask for no parent
 clock?  

Do you suggest we fix this for the existing bindings?

>>> Well, we never seem to reference the HOSC this way, this was always
>>> somewhat explicit. And yes, there is PLL-PERIPH as an input, but we
>>> don't support this yet. So I went with 0 input clocks *for now*: the
>>> driver can then ignore all clocks, so any clock referenced in the DT
>>> later won't cause any harm. This will all be addressed by Samuel's RTC
>>> clock patch, which will also touch the H6, IIRC. And it looks like we
>>> will need to touch the binding anyway then, but can then just *extend*
>>> this.  
>>
>> You mentioned that series several times already and never provided an
>> explanation for what it was supposed to be doing except fixing
>> everything. What's the general plan for that series?

This is my fault for not sending anything yet. Since the initial version of the
driver had the RTC providing HOSC, it depended on converting the existing A100,
H6, and H616 CCU drivers to use .fw_name for parents, since those drivers
hardcode two different global names for HOSC. And I had no opportunit to do that
yet.

[linux-sunxi] Re: [PATCH 52/54] arm64: dts: allwinner: Remove regulator-ramp-delay

[Samuel Holland]

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.

Regards,
Samuel

> Signed-off-by: Maxime Ripard 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 2 --
>  arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts  | 2 --
>  arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts| 2 --
>  3 files changed, 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> index 6249e9e02928..a02644eebbe4 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> @@ -256,7 +256,6 @@ reg_dcdca: dcdca {
>   regulator-always-on;
>   regulator-min-microvolt = <81>;
>   regulator-max-microvolt = <116>;
> - regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-cpu";
>   };
>  
> @@ -264,7 +263,6 @@ reg_dcdcc: dcdcc {
>   regulator-enable-ramp-delay = <32000>;
>   regulator-min-microvolt = <81>;
>   regulator-max-microvolt = <108>;
> - regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-gpu";
>   };
>  
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> index c45d7b7fb39a..69c0293aeb16 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -262,7 +262,6 @@ reg_dcdca: dcdca {
>   regulator-always-on;
>   regulator-min-microvolt = <80>;
>   regulator-max-microvolt = <116>;
> - regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-cpu";
>   };
>  
> @@ -270,7 +269,6 @@ reg_dcdcc: dcdcc {
>   regulator-enable-ramp-delay = <32000>;
>   regulator-min-microvolt = <81>;
>   regulator-max-microvolt = <108>;
> - regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-gpu";
>   };
>  
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> index 1ffd68f43f87..6a1ee4232675 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
> @@ -245,7 +245,6 @@ reg_dcdca: dcdca {
>   regulator-always-on;
>   regulator-min-microvolt = <81>;
>   regulator-max-microvolt = <116>;
> - regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-cpu";
>   };
>  
> @@ -253,7 +252,6 @@ reg_dcdcc: dcdcc {
>   regulator-enable-ramp-delay = <32000>;
>   regulator-min-microvolt = <81>;
>   regulator-max-microvolt = <108>;
> - regulator-ramp-delay = <2500>;
>   regulator-name = "vdd-gpu";
>   };
>  
> 

-- 
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/5469a059-dad1-38d2-9ea4-f1b5fa9ac616%40sholland.org.

[linux-sunxi] Re: [PATCH 02/54] ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema

[Samuel Holland]

On 7/21/21 9:03 AM, Maxime Ripard wrote:
> Bluetooth SCO Link are supported by Linux with a matching device tree
> binding.
> 
> Now that we have the DT validation in place, let's convert the device
> tree bindings for that driver over to a YAML schema.
> 
> The value expected for #sound-dai-cells wasn't documented though, and
> the users were inconsistent. The example didn't list it, and across the
> 4 users we have in tree:
>   - 1 had a cells value of 1, but using only 0 as argument
>   - 1 had a cells value of 0,
>   - 2 didn't have this property at all, behaving as if it was 0,
> 
> It seems like the consensus seems to be that it should be 0, so let's
> enforce it.

The driver has two DAIs: "bt-sco-pcm" and "bt-sco-pcm-wb". If
#sound-dai-cells is 0, only the first DAI can be referenced from a
device tree. So to declare support for wideband PCM, or explicitly
declare a lack of support for it, #sound-dai-cells must be 1.

Regards,
Samuel

> Cc: alsa-de...@alsa-project.org
> Cc: devicet...@vger.kernel.org
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Cc: Samuel Holland 
> Signed-off-by: Maxime Ripard 
> ---
>  .../devicetree/bindings/sound/bt-sco.txt  | 13 ---
>  .../bindings/sound/linux,bt-sco.yaml  | 34 +++
>  2 files changed, 34 insertions(+), 13 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt
>  create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
> 
> diff --git a/Documentation/devicetree/bindings/sound/bt-sco.txt 
> b/Documentation/devicetree/bindings/sound/bt-sco.txt
> deleted file mode 100644
> index 641edf75e184..
> --- a/Documentation/devicetree/bindings/sound/bt-sco.txt
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -Bluetooth-SCO audio CODEC
> -
> -This device support generic Bluetooth SCO link.
> -
> -Required properties:
> -
> -  - compatible : "delta,dfbmcs320" or "linux,bt-sco"
> -
> -Example:
> -
> -codec: bt_sco {
> - compatible = "delta,dfbmcs320";
> -};
> diff --git a/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml 
> b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
> new file mode 100644
> index ..334b508205cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
> @@ -0,0 +1,34 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/linux,bt-sco.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bluetooth SCO Audio Codec Device Tree Bindings
> +
> +maintainers:
> +  - Mark Brown 
> +
> +properties:
> +  '#sound-dai-cells':
> +const: 0
> +
> +  compatible:
> +enum:
> +  - delta,dfbmcs320
> +  - linux,bt-sco
> +
> +required:
> +  - '#sound-dai-cells'
> +  - compatible
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +codec {
> +#sound-dai-cells = <0>;
> +compatible = "linux,bt-sco";
> +};
> +
> +...
> 

-- 
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/e0ba4dab-abe9-9f4b-2795-e85041efa451%40sholland.org.

[linux-sunxi] Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Samuel Holland]

On 6/7/21 7:59 AM, Andre Przywara wrote:
> On Thu, 20 May 2021 21:37:34 -0500
> Samuel Holland  wrote:
> 
> Hi,
> 
>> On 5/19/21 5:41 AM, Andre Przywara wrote:
>>> Add the obvious compatible name to the existing RTC binding.
>>> The actual RTC part of the device uses a different day/month/year
>>> storage scheme, so it's not compatible with the previous devices.
>>>
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
>>> b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> index b1b0ee769b71..178c955f88bf 100644
>>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> @@ -26,6 +26,7 @@ properties:
>>>- const: allwinner,sun50i-a64-rtc
>>>- const: allwinner,sun8i-h3-rtc
>>>- const: allwinner,sun50i-h6-rtc
>>> +  - const: allwinner,sun50i-h616-rtc
>>>  
>>>reg:
>>>  maxItems: 1
>>> @@ -97,7 +98,9 @@ allOf:
>>>properties:
>>>  compatible:
>>>contains:
>>> -const: allwinner,sun50i-h6-rtc
>>> +enum:
>>> +  - allwinner,sun50i-h6-rtc
>>> +  - allwinner,sun50i-h616-rtc
>>>  
>>>  then:
>>>properties:
>>>   
>>
>> This binding is missing a clock reference for the pll-periph0-2x input
>> to the 32kHz clock fanout.
> 
> Right. So do I get this correctly that we don't model the OSC24M input
> explicitly so far in the DT? I only see one possible input clock, which
> is for an optional 32K crystal oscillator.
> And this means we need to change some code also? Because at the moment
> a clock specified is assumed to be the 32K OSC, and having this clock
> means we switch to the external 32K OSC.

Right. The code would need updates to follow the binding.

> And who would decide which clock source to use? What would be the
> reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> divided down 24MHz?

Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
expects 32768 Hz.

> So shall we ignore the PLL based input clock for now, put "0 input
> clocks" in the current binding, then later on extend this to allow
> choosing the PLL? And have it that way that having the PLL reference
> means we use it?

No, the device tree represents the hardware, not whatever happens to be
used by Linux drivers at the time. It should be in the binding
regardless of what the driver does with it.

Though the circular dependency between the clock providers does cause
problems. We cannot get a clk_hw for the PLL-based clock, so we would
have to hardcode a global name for it, which means we aren't really
using the device tree.

We already see this "not really using the binding" with the other CCUs:
the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
"dcxo24M" for the same clock. So moving that clock into the RTC clock
provider would require using both names in one clk_hw simultaneously (or
rather fixing the CCU drivers to get a clk_hw from the DT instead of
referencing by name).

And trying to deal with optional clocks by index is only going to get
more painful over time. For example, with the R329 and D1, the RTC has
the following inputs:
 * DCXO24M (unless you model it inside the RTC)
 * External OSC32k (optional!)
 * The RTC bus gate/reset from the PRCM
 * R-AHB from the PRCM for the RTC SPI clock domain

So it seems time to start using clock-names in the RTC binding.

>> It is also missing a clock reference to the RTC register gate (and that
>> clock is in turn missing from the r_ccu driver).
> 
> Do you mean a gate bit somewhere in the PRCM? Do you have any
> pointer/documentation for that?

Yes, it's bit 0 of PRCM+0x20c, documented in the BSP[1], used in
mainline[2], and verified by experiment.

[1]:
https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/clk/sunxi/clk-sun50iw9.h#L169
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c#n129

> Cheers,
> Andre

Regards,
Samuel

-- 
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/56ad752b-b1c2-cb05-be8b-71c29f271ec9%40sholland.org.

[linux-sunxi] Re: [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)

[Samuel Holland]

On 5/19/21 5:41 AM, Andre Przywara wrote:
> The AXP305 PMIC used in AXP805 seems to be fully compatible to the
  ^^
Typo? Do you mean "used with the H616 SoC"?

> AXP805 PMIC, so add the proper chain of compatible strings.
> 
> Also at least on one board (Orangepi Zero2) there is no interrupt line
> connected to the CPU, so make the "interrupts" property optional.
> 
> Signed-off-by: Andre Przywara 
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 4991a6415796..4fd748101e3c 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -26,10 +26,10 @@ Required properties:
>  * "x-powers,axp803"
>  * "x-powers,axp806"
>  * "x-powers,axp805", "x-powers,axp806"
> +* "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"
   ^^
This should be x-powers,axp305.

Regards,
Samuel

>  * "x-powers,axp809"
>  * "x-powers,axp813"
>  - reg: The I2C slave address or RSB hardware address for the AXP chip
> -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - interrupt-controller: The PMIC has its own internal IRQs
>  - #interrupt-cells: Should be set to 1
>  
> @@ -43,6 +43,7 @@ more information:
>   AXP20x/LDO3: software-based implementation
>  
>  Optional properties:
> +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
> AXP152/20X: range:  750-1875, Default: 1.5 MHz
> AXP22X/8XX: range: 1800-4050, Default: 3   MHz
> 

-- 
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/7ebfaef7-5cf2-e60c-99ef-4275c873e72d%40sholland.org.

[linux-sunxi] Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string

[Samuel Holland]

Andre,

On 5/19/21 5:41 AM, Andre Przywara wrote:
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> 
> Signed-off-by: Andre Przywara 
> ---
>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> index b1b0ee769b71..178c955f88bf 100644
> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> @@ -26,6 +26,7 @@ properties:
>- const: allwinner,sun50i-a64-rtc
>- const: allwinner,sun8i-h3-rtc
>- const: allwinner,sun50i-h6-rtc
> +  - const: allwinner,sun50i-h616-rtc
>  
>reg:
>  maxItems: 1
> @@ -97,7 +98,9 @@ allOf:
>properties:
>  compatible:
>contains:
> -const: allwinner,sun50i-h6-rtc
> +enum:
> +  - allwinner,sun50i-h6-rtc
> +  - allwinner,sun50i-h616-rtc
>  
>  then:
>properties:
> 

This binding is missing a clock reference for the pll-periph0-2x input
to the 32kHz clock fanout.

It is also missing a clock reference to the RTC register gate (and that
clock is in turn missing from the r_ccu driver).

Regards,
Samuel

-- 
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/99a2069b-99e9-9b47-12a6-aae01c7f59dc%40sholland.org.

Re: [linux-sunxi] [PATCH] net: sun8i-emac: Fix pinmux setup for Allwinner H5

[Samuel Holland]

On 4/16/21 6:05 AM, Andre Przywara wrote:
> Commit eb5a2b671075 ("net: sun8i-emac: Determine pinmux based on SoC,
> not EMAC type") switched the pinmux setup over to look at
> CONFIG_MACH_SUN* symbols, to find the appropriate mux value.
> Unfortunately this patch missed to check for the H5, which is
> pin-compatible to the H3, but uses a different Kconfig symbol (because
> it has ARMv8 vs. ARMv7 cores).
> 
> Replace the pure SUN8I_H3 symbol with the joint SUNXI_H3_H5 one, which is
> there to cover the peripherals common to both SoCs.
> Also explicitly list each supported SoC, and have an error message in the
> fallback case, to avoid those problems in the future.
> 
> This fixes Ethernet support on all H5 boards.
> 
> Signed-off-by: Andre Przywara 

Tested-by: Samuel Holland  # Orange Pi PC2

Also tested on H3 (Orange Pi Plus 2E) and A64 (Orange Pi Win) to verify
no regression.

-- 
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/915d17cc-51fc-a763-ab20-c2ec72a278f9%40sholland.org.

[linux-sunxi] Re: [PATCH 2/2] sunxi: dts: H616: Drop reserved-memory node

[Samuel Holland]

On 3/30/21 8:28 AM, Jagan Teki wrote:
> On Tue, Mar 30, 2021 at 6:31 PM Andre Przywara  wrote:
>>
>> Trusted Firmware now adds the /reserved-memory subnode to the DT at
>> runtime[1], putting in the right values.
>>
>> Drop our hard-coded version, as this might clash with the actual values
>> (which have also changed), and rely on TF-A to add the node.
>>
>> [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7770
>>
>> Signed-off-by: Andre Przywara 

Reviewed-by: Samuel Holland 

>> ---
>>  arch/arm/dts/sun50i-h616.dtsi | 12 
>>  1 file changed, 12 deletions(-)
>>
>> diff --git a/arch/arm/dts/sun50i-h616.dtsi b/arch/arm/dts/sun50i-h616.dtsi
>> index 953e8fac20f..dd4d2f3 100644
>> --- a/arch/arm/dts/sun50i-h616.dtsi
>> +++ b/arch/arm/dts/sun50i-h616.dtsi
>> @@ -51,18 +51,6 @@
>> };
>> };
>>
>> -   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;
>> -   };
>> -   };
>> -
> 
> As said always. it's better to not touch Linux dts files. If the same
> fix same available in Linux add SHA1 on the commit message otherwise
> keep /delete-node on -u-boot.dtsi. This how we are maintaining sofar
> at least on sunxi.

This file has not yet been added to the Linux tree, so that rule does not apply
in this case.

Cheers,
Samuel

> Jagan.
> 

-- 
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/912b7c69-fdac-8e2d-9d52-b28141beb299%40sholland.org.

[linux-sunxi] Re: [PATCH 1/2] sunxi: H616: Change TF-A load address to beginning of DRAM

[Samuel Holland]

On 3/30/21 8:01 AM, Andre Przywara wrote:
> Loading Trusted-Firmware's BL31 at 16KB into DRAM was originally a hack
> to allow sharing more code with the other SoCs (which use this offset
> in SRAM). However there is no longer a reason for that, as the
> problematic macros have been properly separated there.
> 
> The latest (and hopefully final) TF-A code drop now changes the load
> address to the beginning of DRAM, which is also more easily protected
> by the Trustzone memory controller (code to be done).
> 
> Adjust the load address of BL31 now, to avoid any issues with
> incompatible versions later on (the TF-A patches are about to be merged).
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Samuel Holland 

> ---
>  arch/arm/dts/sunxi-u-boot.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> index abe629c55e5..cd096bf2a06 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -4,7 +4,7 @@
>  #define BL31_ADDR 0x104000
>  #define  SCP_ADDR 0x114000
>  #elif defined(CONFIG_MACH_SUN50I_H616)
> -#define BL31_ADDR 0x40004000
> +#define BL31_ADDR 0x4000
>  #else
>  #define BL31_ADDR  0x44000
>  #define  SCP_ADDR  0x5
> 

-- 
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/cb8f6c4d-6a1f-d3ca-ae96-af96ece58889%40sholland.org.

[linux-sunxi] Re: [RFC PATCH] arm64: dts: allwinner: a64/h5: Add CPU idle states

[Samuel Holland]

On 3/22/21 8:56 PM, Andre Przywara wrote:
>> I'm sending this patch as an RFC because it raises questions about how
>> we handle firmware versioning. How far back does (or should) our support
>> for old TF-A and Crust versions go?
>>
>> cpuidle has a problem that without working firmware support, CPUs will
>> enter idle states and be unable to wake up. As a result, the system will
>> hang at some point during boot, usually before getting to userspace.
>>
>> For over a year[0], TF-A has exposed the PSCI CPU_SUSPEND function when
>> a SCPI implementation is present[1]. Implementing CPU_SUSPEND is
>> required for implementing SYSTEM_SUSPEND[2], even if CPU_SUSPEND is not
>> itself used for anything. 
>>
>> However, there was no code to actually wake up a CPU once it called the
>> CPU_SUSPEND function, because I could not find the register providing
>> the necessary information. The fact that CPU_SUSPEND was broken affected
>> nobody, because nothing ever called it -- there were no idle states in
>> the DTS. In hindsight, what I should have done was always return failure
>> from sunxi_validate_power_state(), but that ship has long sailed.
>>
>> I finally found the elusive register and implemented the wakeup code
>> earlier this month[3]. So now, CPU_SUSPEND actually works, if all of
>> your firmware is up to date, and cpuidle works if you add the states in
>> your device tree.
>>
>> Unfortunately, there is currently nothing verifying that compatibility.
>> So you can get into four possible scenarios:
>>   1) No idle states in DTS, any firmware => Linux works, with baseline
>>  power consumption.
>>   2) Idle states added to DTS, no Crust/SCPI => Linux works, but every
>>  attempt to enter an idle state is rejected because CPU_SUSPEND is
>>  not hooked up. So power consumption increases by a sizable amount.
>>   3) Idle states added to DTS, "old" Crust/SCPI (before [3]) => Linux
>>  fails to boot, because CPUs never return from idle states.
>>   4) Idle states added to DTS, "new" Crust/SCPI (after [3]) => Linux
>>  works, with improved power consumption compared to the baseline.
>>
>> Obviously, we want to prevent scenario 3 if possible.
> 
> So I think the core of the problem is that the DT describes some
> firmware feature, but we have the DT bundled with the kernel, not the
> firmware.

I would say the core problem is that the firmware lies about supporting
PSCI CPU_SUSPEND. Linux shouldn't be calling CPU_SUSPEND if the firmware
declares it as unavailable, regardless of what is in the DTS.
(Technically, per the PSCI standard, CPU_SUSPEND is a mandatory
function, but a quick survey of the TF-A platforms shows it is far from
universally implemented.)

> So is there any way we can detect an older crust version in U-Boot,
> then remove any potential idle states from the DT?

Let's assume that we are using a functioning SoC (H3) or the secure fuse
is blown (A64) and therefore U-Boot cannot access SRAM A2. I can think
of three ways it can learn about crust:

a) PSCI_FEATURES (e.g. is CPU_SUSPEND supported)
b) Metadata in the FIT image
c) Custom SMCs

TF-A has some additional methods available:

d) The SCPI-reported firmware version
e) The magic number at the beginning of the firmware binary

> Granted, this requires recent U-Boot as well, but at least we could try
> to mitigate the worst case a bit?

If we're okay with modifying firmware to solve this problem, then I
propose the following solution:

1) Version bump crust or change its magic number.
2) Modify TF-A to only report CPU_SUSPEND as available if it detects the
   new crust version. This would involve conditionally setting
   sunxi_scpi_psci_ops.validate_power_state, and updating psci_setup.c
   to also check for .validate_power_state when setting psci_caps.
3) Modify the Linux PSCI client to respect PSCI_FEATURES when setting
   psci_ops.cpu_suspend. cpuidle-psci checks for this function before
   setting up idle states.
4) Finally, after some time, add the idle states to the DTS.

In fact, this solution solves both scenarios 2 and 3, because it also
takes care of the native PM implementation, which doesn't implement
CPU_SUSPEND at all.

Does that sound workable?

Regards,
Samuel

> A better solution could be to only *add* the idle states if the rest of
> the firmware is deemed worthy. So the mainline DTs would not carry the
> properties in the first place, and only U-Boot adds them, on detecting
> a capable firmware?
> Admittedly this changes the "flow" of the DT, where the kernel is the
> authority, but it might help to solve this problem?
> 
> Or any other way, which involves U-Boot patching the DTB? (This would
> apply to the DTB passed to the kernel, regardless of where and when
> it's loaded from)
> 
> Any opinions?
> 
> Cheers,
> Andre
> 
>> Enter the current patch: I chose the arm,psci-suspend-param values
>> specifically so they would be _rejected_ by the current TF-A code. This
>> makes scenario 3 behave like scenario 2. I 

[linux-sunxi] Re: [PATCH v4 2/4] drm: sun4i: dsi: Add bridge support

[Samuel Holland]

On 3/22/21 9:01 AM, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output which
> can have an option to connect DSI interface by means of bridge
> converter.
> 
> This DSI to non-DSI bridge converter would require a bridge
> driver that would communicate the DSI controller for bridge
> functionalities.
> 
> So, add support for bridge functionalities in Allwinner DSI
> controller.
> 
> Cc: Samuel Holland 
> Signed-off-by: Jagan Teki 
> ---
> Note: 
> Samuel Holland, The existing kms hotplug dropped in order to 
> attach the bridge properly. 
> 
> However, I did try several ways to support hotplug with the 
> bridge but it's resulting in a deadlock where bind never attach 
> bridge until bridge pointer found and bridge pointer cannot 
> found until bind finishes. Any inputs on this would be appreciated.

The intended behavior is that sun6i_dsi_bind() is independent of any DSI
device. And sun6i_dsi_attach() must only be called after bind completes
and the DRM device is registered. This design allows the rest of the
display engine (such as the HDMI output) to work even if no panel is
listed in the device tree, or if a panel driver is missing.

> Changes for v4:
> - none
> Changes for v3:
> - updated with new API's 
> 
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 34 +-
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h |  2 +-
>  2 files changed, 23 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 2e9e7b2d4145..39321299dc27 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -773,6 +773,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   if (dsi->panel)
>   drm_panel_prepare(dsi->panel);
>  
> + if (dsi->panel_bridge)
> + dsi->panel_bridge->funcs->pre_enable(dsi->panel_bridge);
> +
>   /*
>* FIXME: This should be moved after the switch to HS mode.
>*
> @@ -788,6 +791,9 @@ static void sun6i_dsi_encoder_enable(struct drm_encoder 
> *encoder)
>   if (dsi->panel)
>   drm_panel_enable(dsi->panel);
>  
> + if (dsi->panel_bridge)
> + dsi->panel_bridge->funcs->enable(dsi->panel_bridge);
> +
>   sun6i_dsi_start(dsi, DSI_START_HSC);
>  
>   udelay(1000);
> @@ -804,6 +810,9 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder 
> *encoder)
>   if (dsi->panel) {
>   drm_panel_disable(dsi->panel);
>   drm_panel_unprepare(dsi->panel);
> + } else if (dsi->panel_bridge) {
> + dsi->panel_bridge->funcs->disable(dsi->panel_bridge);
> + dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
>   }
>  
>   phy_power_off(dsi->dphy);
> @@ -964,23 +973,17 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
>   struct mipi_dsi_device *device)
>  {
>   struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
> - struct drm_panel *panel;
>   int ret;
>  
>   ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
> -   , NULL);
> +   >panel, >panel_bridge);
>   if (ret)
>   return ret;
>  
> - if (!dsi->drm || !dsi->drm->registered)
> - return -EPROBE_DEFER;
> -
> - dsi->panel = panel;
>   dsi->device = device;
>  
> - drm_kms_helper_hotplug_event(dsi->drm);
> -
> - dev_info(host->dev, "Attached device %s\n", device->name);
> + dev_info(host->dev, "Attached %s %s\n",
> +  device->name, dsi->panel ? "panel" : "bridge");
>  
>   return 0;
>  }
> @@ -991,9 +994,10 @@ static int sun6i_dsi_detach(struct mipi_dsi_host *host,
>   struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
>  
>   dsi->panel = NULL;
> + dsi->panel_bridge = NULL;
>   dsi->device = NULL;
>  
> - drm_kms_helper_hotplug_event(dsi->drm);
> + drm_of_panel_bridge_remove(dsi->dev->of_node, 0, 0);
>  
>   return 0;
>  }
> @@ -1082,7 +1086,13 @@ static int sun6i_dsi_bind(struct device *dev, struct 
> device *master,
>  
>   drm_connector_attach_encoder(>connector, >encoder);
>  
> - dsi->drm = drm;
> + if (dsi->panel_bridge) {
> + ret = drm_bridge_attach(>encoder, dsi->panel_bridge, NULL, 
> 0);
> + if (ret) {
> +

[linux-sunxi] Re: [PATCH v4 1/4] drm: sun4i: dsi: Use drm_of_find_panel_or_bridge

[Samuel Holland]

On 3/23/21 5:53 PM, Laurent Pinchart wrote:
> Hi Jagan,
> 
> Thank you for the patch.
> 
> On Mon, Mar 22, 2021 at 07:31:49PM +0530, Jagan Teki wrote:
>> Replace of_drm_find_panel with drm_of_find_panel_or_bridge
>> for finding panel, this indeed help to find the bridge if
>> bridge support added.
>>
>> Added NULL in bridge argument, same will replace with bridge
>> parameter once bridge supported.
>>
>> Signed-off-by: Jagan Teki 
> 
> Looks good, there should be no functional change.

Actually this breaks all existing users of this driver, see below.

> Reviewed-by: Laurent Pinchart 
> 
>> ---
>> Changes for v4, v3:
>> - none
>>
>>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 ---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
>> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> index 4f5efcace68e..2e9e7b2d4145 100644
>> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> @@ -21,6 +21,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -963,10 +964,14 @@ static int sun6i_dsi_attach(struct mipi_dsi_host *host,
>>  struct mipi_dsi_device *device)
>>  {
>>  struct sun6i_dsi *dsi = host_to_sun6i_dsi(host);
>> -struct drm_panel *panel = of_drm_find_panel(device->dev.of_node);

This is using the OF node of the DSI device, which is a direct child of
the DSI host's OF node. There is no OF graph involved.

>> +struct drm_panel *panel;
>> +int ret;
>> +
>> +ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 0, 0,
>> +  , NULL);

However, this function expects to find the panel using OF graph. This
does not work with existing device trees (PinePhone, PineTab) which do
not use OF graph to connect the panel. And it cannot work, because the
DSI host's binding specifies a single port: the input port from the
display engine.

Regards,
Samuel

>> +if (ret)
>> +return ret;
>>  
>> -if (IS_ERR(panel))
>> -return PTR_ERR(panel);
>>  if (!dsi->drm || !dsi->drm->registered)
>>  return -EPROBE_DEFER;
>>  
> 

-- 
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/f47bc0ad-dbd6-05b5-aaec-2e3256e3715a%40sholland.org.

[linux-sunxi] [RFC PATCH] arm64: dts: allwinner: a64/h5: Add CPU idle states

[Samuel Holland]

Powering off idle CPUs saves about 33 mW compared to using WFI only.
Additional power savings are possible by idling the L2 and downclocking
the cluster when all CPUs are idle.

Entry and exit latency were measured using a logic analyzer, with GPIO
pins toggled in Linux after the calls to trace_cpu_idle() in
cpuidle_enter_state(), and in the power management firmware after CPU
power-off completes and immediately after detecting an interrupt.

800 us and 1500 us are worst-case values, largely driven by the fact
that the power management firmware is single threaded. It can only
handle commands to power off CPUs one at a time, and it cannot process
any commands while powering on a CPU in response to an interrupt.

The cluster suspend process reliably takes 36 us; I rounded this up to
50 us. If all CPUs enter the cluster idle state at the same time, exit
latency is actually reduced, because there is no contention in that
case. However, if only some CPUs enter the cluster idle state, behavior
is the same as for CPU idle.

Polling delay for the power management firmware to detect a pending
interrupt is insignificant; it is less than 20 us.

min-residency was chosen as the point where enabling the idle state
consumed no more average power than disabling the idle state at a
variety of interrupt rates.

Signed-off-by: Samuel Holland 
---

I'm sending this patch as an RFC because it raises questions about how
we handle firmware versioning. How far back does (or should) our support
for old TF-A and Crust versions go?

cpuidle has a problem that without working firmware support, CPUs will
enter idle states and be unable to wake up. As a result, the system will
hang at some point during boot, usually before getting to userspace.

For over a year[0], TF-A has exposed the PSCI CPU_SUSPEND function when
a SCPI implementation is present[1]. Implementing CPU_SUSPEND is
required for implementing SYSTEM_SUSPEND[2], even if CPU_SUSPEND is not
itself used for anything. 

However, there was no code to actually wake up a CPU once it called the
CPU_SUSPEND function, because I could not find the register providing
the necessary information. The fact that CPU_SUSPEND was broken affected
nobody, because nothing ever called it -- there were no idle states in
the DTS. In hindsight, what I should have done was always return failure
from sunxi_validate_power_state(), but that ship has long sailed.

I finally found the elusive register and implemented the wakeup code
earlier this month[3]. So now, CPU_SUSPEND actually works, if all of
your firmware is up to date, and cpuidle works if you add the states in
your device tree.

Unfortunately, there is currently nothing verifying that compatibility.
So you can get into four possible scenarios:
  1) No idle states in DTS, any firmware => Linux works, with baseline
 power consumption.
  2) Idle states added to DTS, no Crust/SCPI => Linux works, but every
 attempt to enter an idle state is rejected because CPU_SUSPEND is
 not hooked up. So power consumption increases by a sizable amount.
  3) Idle states added to DTS, "old" Crust/SCPI (before [3]) => Linux
 fails to boot, because CPUs never return from idle states.
  4) Idle states added to DTS, "new" Crust/SCPI (after [3]) => Linux
 works, with improved power consumption compared to the baseline.

Obviously, we want to prevent scenario 3 if possible.

Enter the current patch: I chose the arm,psci-suspend-param values
specifically so they would be _rejected_ by the current TF-A code. This
makes scenario 3 behave like scenario 2. I then have some follow-up TF-A
patches (not yet submitted) to switch to the new parameter encoding[4].

This brings me back to my original question. Once the TF-A patches in
[4] are merged, scenario 3 (with an updated TF-A but an old Crust) would
fail to boot again. Do we care?

Should I implement some kind of runtime version checking, so TF-A can
disable CPU_SUSPEND if it would be broken? Or instead, should we wait
some amount of time to merge this patch (or the patches at [4]) and
assume people have upgraded?

Where would people expect this sort of possibly-breaking change to be
documented?

Separately, since I assume most A64/H5 users (outside of LibreELEC and
the PinePhone) are not using Crust, scenario 2 would be very common. If
merging this patch increases their idle power draw by 500 mW, is that an
acceptable cost for decreasing other users' idle power draw by 50 mW?

Sorry for the wall of text,
Samuel

[0]: 
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/allwinner/common/sunxi_pm.c?id=e382c88e2a26995099bb931d49e754dcaebc5593
[1]: 
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/allwinner/common/sunxi_scpi_pm.c?id=2e0e51f42586826a1f6f6c1e532f90e6df642cf5#n190
[2]: 
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/psci/psci_setup.c?id=2e0e51f42586826a1f6f6c1e532f90e6df642cf5#n251
[3]: https:/

[linux-sunxi] [PATCH net-next v2 0/5] dwmac-sun8i cleanup and shutdown hook

[Samuel Holland]

These patches clean up some things I noticed while fixing suspend/resume
behavior. The first four are minor code improvements. The last one adds
a shutdown hook to minimize power consumption on boards without a PMIC.

Changes v1 to v2:
  - Note the assumption of exclusive reset controller access in patch 3

Samuel Holland (5):
  net: stmmac: dwmac-sun8i: Return void from PHY unpower
  net: stmmac: dwmac-sun8i: Remove unnecessary PHY power check
  net: stmmac: dwmac-sun8i: Use reset_control_reset
  net: stmmac: dwmac-sun8i: Minor probe function cleanup
  net: stmmac: dwmac-sun8i: Add a shutdown callback

 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 33 ---
 1 file changed, 21 insertions(+), 12 deletions(-)

-- 
2.26.2

-- 
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/20210217042006.54559-1-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next v2 5/5] net: stmmac: dwmac-sun8i: Add a shutdown callback

[Samuel Holland]

The Ethernet MAC and PHY are usually major consumers of power on boards
which may not be able to fully power off (those with no PMIC). Powering
down the MAC and internal PHY saves power while these boards are "off".

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a3d333b652836..6b75cf2603ffc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1284,6 +1284,15 @@ static int sun8i_dwmac_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static void sun8i_dwmac_shutdown(struct platform_device *pdev)
+{
+   struct net_device *ndev = platform_get_drvdata(pdev);
+   struct stmmac_priv *priv = netdev_priv(ndev);
+   struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+
+   sun8i_dwmac_exit(pdev, gmac);
+}
+
 static const struct of_device_id sun8i_dwmac_match[] = {
{ .compatible = "allwinner,sun8i-h3-emac",
.data = _variant_h3 },
@@ -1304,6 +1313,7 @@ MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
 static struct platform_driver sun8i_dwmac_driver = {
.probe  = sun8i_dwmac_probe,
.remove = sun8i_dwmac_remove,
+   .shutdown = sun8i_dwmac_shutdown,
.driver = {
.name   = "dwmac-sun8i",
.pm = _pltfr_pm_ops,
-- 
2.26.2

-- 
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/20210217042006.54559-6-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next v2 2/5] net: stmmac: dwmac-sun8i: Remove unnecessary PHY power check

[Samuel Holland]

sun8i_dwmac_unpower_internal_phy already checks if the PHY is powered,
so there is no need to do it again here.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 8e505019adf85..3c3d0b99d3e8c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1018,10 +1018,8 @@ static void sun8i_dwmac_exit(struct platform_device 
*pdev, void *priv)
 {
struct sunxi_priv_data *gmac = priv;
 
-   if (gmac->variant->soc_has_internal_phy) {
-   if (gmac->internal_phy_powered)
-   sun8i_dwmac_unpower_internal_phy(gmac);
-   }
+   if (gmac->variant->soc_has_internal_phy)
+   sun8i_dwmac_unpower_internal_phy(gmac);
 
clk_disable_unprepare(gmac->tx_clk);
 
-- 
2.26.2

-- 
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/20210217042006.54559-3-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next v2 4/5] net: stmmac: dwmac-sun8i: Minor probe function cleanup

[Samuel Holland]

Adjust the spacing and use an explicit "return 0" in the success path
to make the function easier to parse.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index b61f442ed3033..a3d333b652836 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1229,6 +1229,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 
ndev = dev_get_drvdata(>dev);
priv = netdev_priv(ndev);
+
/* The mux must be registered after parent MDIO
 * so after stmmac_dvr_probe()
 */
@@ -1247,7 +1248,8 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
goto dwmac_remove;
}
 
-   return ret;
+   return 0;
+
 dwmac_mux:
reset_control_put(gmac->rst_ephy);
clk_put(gmac->ephy_clk);
-- 
2.26.2

-- 
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/20210217042006.54559-5-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next v2 3/5] net: stmmac: dwmac-sun8i: Use reset_control_reset

[Samuel Holland]

Use the appropriate function instead of reimplementing it,
and update the error message to match the code.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 3c3d0b99d3e8c..b61f442ed3033 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -805,12 +805,12 @@ static int sun8i_dwmac_power_internal_phy(struct 
stmmac_priv *priv)
 
/* Make sure the EPHY is properly reseted, as U-Boot may leave
 * it at deasserted state, and thus it may fail to reset EMAC.
+*
+* This assumes the driver has exclusive access to the EPHY reset.
 */
-   reset_control_assert(gmac->rst_ephy);
-
-   ret = reset_control_deassert(gmac->rst_ephy);
+   ret = reset_control_reset(gmac->rst_ephy);
if (ret) {
-   dev_err(priv->device, "Cannot deassert internal phy\n");
+   dev_err(priv->device, "Cannot reset internal PHY\n");
clk_disable_unprepare(gmac->ephy_clk);
return ret;
}
-- 
2.26.2

-- 
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/20210217042006.54559-4-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next v2 1/5] net: stmmac: dwmac-sun8i: Return void from PHY unpower

[Samuel Holland]

This is a deinitialization function that always returned zero, and that
return value was always ignored. Have it return void instead.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a5e0eff4a3874..8e505019adf85 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -820,15 +820,14 @@ static int sun8i_dwmac_power_internal_phy(struct 
stmmac_priv *priv)
return 0;
 }
 
-static int sun8i_dwmac_unpower_internal_phy(struct sunxi_priv_data *gmac)
+static void sun8i_dwmac_unpower_internal_phy(struct sunxi_priv_data *gmac)
 {
if (!gmac->internal_phy_powered)
-   return 0;
+   return;
 
clk_disable_unprepare(gmac->ephy_clk);
reset_control_assert(gmac->rst_ephy);
gmac->internal_phy_powered = false;
-   return 0;
 }
 
 /* MDIO multiplexing switch function
-- 
2.26.2

-- 
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/20210217042006.54559-2-samuel%40sholland.org.

[linux-sunxi] Re: [PATCH net-next RESEND 3/5] net: stmmac: dwmac-sun8i: Use reset_control_reset

[Samuel Holland]

On 2/8/21 10:29 AM, Alexander Duyck wrote:
> On Sun, Feb 7, 2021 at 10:32 PM Samuel Holland  wrote:
>>
>> Use the appropriate function instead of reimplementing it,
>> and update the error message to match the code.
>>
>> Reviewed-by: Chen-Yu Tsai 
>> Signed-off-by: Samuel Holland 
>> ---
>>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
>> index 3c3d0b99d3e8..0e8d88417251 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
>> @@ -806,11 +806,9 @@ static int sun8i_dwmac_power_internal_phy(struct 
>> stmmac_priv *priv)
>> /* Make sure the EPHY is properly reseted, as U-Boot may leave
>>  * it at deasserted state, and thus it may fail to reset EMAC.
>>  */
>> -   reset_control_assert(gmac->rst_ephy);
>> -
>> -   ret = reset_control_deassert(gmac->rst_ephy);
>> +   ret = reset_control_reset(gmac->rst_ephy);
>> if (ret) {
>> -   dev_err(priv->device, "Cannot deassert internal phy\n");
>> +   dev_err(priv->device, "Cannot reset internal PHY\n");
>> clk_disable_unprepare(gmac->ephy_clk);
>> return ret;
>> }
> 
> I'm assuming you have exclusive access to the phy and this isn't a
> shared line? Just wanting to confirm since the function call has the
> following comment in the header for the documentation.

Yes, this driver has exclusive access:

gmac->rst_ephy = of_reset_control_get_exclusive(iphynode, NULL);

And this is a reset line for the Ethernet PHY inside the SoC, that as
far as I can tell is not shared with anything else.

>  * Consumers must not use reset_control_(de)assert on shared reset lines when
>  * reset_control_reset has been used.
>  *
> 
> If that is the case it might not hurt to add some documentation to
> your call to reset_control_reset here explaining that it is safe to do
> so since you have exclusive access.

I can expand the comment above this line for v2.

Cheers,
Samuel

-- 
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/b12c9e59-cb96-dd88-e2b7-31517bd0f63e%40sholland.org.

[linux-sunxi] Re: [PATCH] i2c: mv64xxx: Fix check for missing clock

[Samuel Holland]

On 2/8/21 7:20 AM, Andrew Lunn wrote:
> On Mon, Feb 08, 2021 at 12:31:34AM -0600, Samuel Holland wrote:
>> On 2/8/21 12:28 AM, Samuel Holland wrote:
>>> In commit e5c02cf54154 ("i2c: mv64xxx: Add runtime PM support"), error
>>> pointers to optional clocks were replaced by NULL to simplify the resume
>>> callback implementation. However, that commit missed that the IS_ERR
>>> check in mv64xxx_of_config should be replaced with a NULL check. As a
>>> result, the check always passes, even for an invalid device tree.
>>
>> Sorry, please ignore this unrelated patch. I accidentally copied it to
>> the wrong directory before sending this series.
> 
> Hi Samuel
> 
> This patch looks correct. But i don't see it in i2c/for-next, where as
> e5c02cf54154 is. I just want to make sure it does not get lost...

Thanks for the concern. I had already sent it separately[0], to the
appropriate maintainers, so this submission was a duplicate.

Cheers,
Samuel

[0]:
https://lore.kernel.org/lkml/20210208061922.10073-1-sam...@sholland.org/

>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/089df4b2-8cd5-187a-55cf-0e558858a7d1%40sholland.org.

[linux-sunxi] Re: [PATCH] i2c: mv64xxx: Fix check for missing clock

[Samuel Holland]

On 2/8/21 12:28 AM, Samuel Holland wrote:
> In commit e5c02cf54154 ("i2c: mv64xxx: Add runtime PM support"), error
> pointers to optional clocks were replaced by NULL to simplify the resume
> callback implementation. However, that commit missed that the IS_ERR
> check in mv64xxx_of_config should be replaced with a NULL check. As a
> result, the check always passes, even for an invalid device tree.

Sorry, please ignore this unrelated patch. I accidentally copied it to
the wrong directory before sending this series.

Samuel

-- 
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/4f696b13-2475-49f2-5d75-f2120e159142%40sholland.org.

[linux-sunxi] [PATCH net-next RESEND 0/5] dwmac-sun8i cleanup and shutdown hook

[Samuel Holland]

These patches clean up some things I noticed while fixing suspend/resume
behavior. The first four are minor code improvements. The last one adds
a shutdown hook to minimize power consumption on boards without a PMIC.

Now that the fixes series is merged, I'm resending this series rebased
on top of net-next and with Chen-Yu's Reviewed-by tags.

Samuel Holland (5):
  net: stmmac: dwmac-sun8i: Return void from PHY unpower
  net: stmmac: dwmac-sun8i: Remove unnecessary PHY power check
  net: stmmac: dwmac-sun8i: Use reset_control_reset
  net: stmmac: dwmac-sun8i: Minor probe function cleanup
  net: stmmac: dwmac-sun8i: Add a shutdown callback

 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 31 ---
 1 file changed, 19 insertions(+), 12 deletions(-)

-- 
2.26.2

-- 
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/20210208062859.11429-1-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next RESEND 2/5] net: stmmac: dwmac-sun8i: Remove unnecessary PHY power check

[Samuel Holland]

sun8i_dwmac_unpower_internal_phy already checks if the PHY is powered,
so there is no need to do it again here.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 8e505019adf8..3c3d0b99d3e8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1018,10 +1018,8 @@ static void sun8i_dwmac_exit(struct platform_device 
*pdev, void *priv)
 {
struct sunxi_priv_data *gmac = priv;
 
-   if (gmac->variant->soc_has_internal_phy) {
-   if (gmac->internal_phy_powered)
-   sun8i_dwmac_unpower_internal_phy(gmac);
-   }
+   if (gmac->variant->soc_has_internal_phy)
+   sun8i_dwmac_unpower_internal_phy(gmac);
 
clk_disable_unprepare(gmac->tx_clk);
 
-- 
2.26.2

-- 
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/20210208062859.11429-4-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next RESEND 5/5] net: stmmac: dwmac-sun8i: Add a shutdown callback

[Samuel Holland]

The Ethernet MAC and PHY are usually major consumers of power on boards
which may not be able to fully power off (those with no PMIC). Powering
down the MAC and internal PHY saves power while these boards are "off".

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4638d4203af5..926e8d5e8963 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1282,6 +1282,15 @@ static int sun8i_dwmac_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static void sun8i_dwmac_shutdown(struct platform_device *pdev)
+{
+   struct net_device *ndev = platform_get_drvdata(pdev);
+   struct stmmac_priv *priv = netdev_priv(ndev);
+   struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+
+   sun8i_dwmac_exit(pdev, gmac);
+}
+
 static const struct of_device_id sun8i_dwmac_match[] = {
{ .compatible = "allwinner,sun8i-h3-emac",
.data = _variant_h3 },
@@ -1302,6 +1311,7 @@ MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
 static struct platform_driver sun8i_dwmac_driver = {
.probe  = sun8i_dwmac_probe,
.remove = sun8i_dwmac_remove,
+   .shutdown = sun8i_dwmac_shutdown,
.driver = {
.name   = "dwmac-sun8i",
.pm = _pltfr_pm_ops,
-- 
2.26.2

-- 
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/20210208062859.11429-7-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next RESEND 3/5] net: stmmac: dwmac-sun8i: Use reset_control_reset

[Samuel Holland]

Use the appropriate function instead of reimplementing it,
and update the error message to match the code.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 3c3d0b99d3e8..0e8d88417251 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -806,11 +806,9 @@ static int sun8i_dwmac_power_internal_phy(struct 
stmmac_priv *priv)
/* Make sure the EPHY is properly reseted, as U-Boot may leave
 * it at deasserted state, and thus it may fail to reset EMAC.
 */
-   reset_control_assert(gmac->rst_ephy);
-
-   ret = reset_control_deassert(gmac->rst_ephy);
+   ret = reset_control_reset(gmac->rst_ephy);
if (ret) {
-   dev_err(priv->device, "Cannot deassert internal phy\n");
+   dev_err(priv->device, "Cannot reset internal PHY\n");
clk_disable_unprepare(gmac->ephy_clk);
return ret;
}
-- 
2.26.2

-- 
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/20210208062859.11429-5-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next RESEND 4/5] net: stmmac: dwmac-sun8i: Minor probe function cleanup

[Samuel Holland]

Adjust the spacing and use an explicit "return 0" in the success path
to make the function easier to parse.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 0e8d88417251..4638d4203af5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1227,6 +1227,7 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 
ndev = dev_get_drvdata(>dev);
priv = netdev_priv(ndev);
+
/* The mux must be registered after parent MDIO
 * so after stmmac_dvr_probe()
 */
@@ -1245,7 +1246,8 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
goto dwmac_remove;
}
 
-   return ret;
+   return 0;
+
 dwmac_mux:
reset_control_put(gmac->rst_ephy);
clk_put(gmac->ephy_clk);
-- 
2.26.2

-- 
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/20210208062859.11429-6-samuel%40sholland.org.

[linux-sunxi] [PATCH] i2c: mv64xxx: Fix check for missing clock

[Samuel Holland]

In commit e5c02cf54154 ("i2c: mv64xxx: Add runtime PM support"), error
pointers to optional clocks were replaced by NULL to simplify the resume
callback implementation. However, that commit missed that the IS_ERR
check in mv64xxx_of_config should be replaced with a NULL check. As a
result, the check always passes, even for an invalid device tree.

Fixes: e5c02cf54154 ("i2c: mv64xxx: Add runtime PM support")
Reported-by: Dan Carpenter 
Signed-off-by: Samuel Holland 
---
 drivers/i2c/busses/i2c-mv64xxx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index b03c344323d1..c590d36b5fd1 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -813,7 +813,7 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
 * need to know tclk in order to calculate bus clock
 * factors.
 */
-   if (IS_ERR(drv_data->clk)) {
+   if (!drv_data->clk) {
rc = -ENODEV;
goto out;
}
-- 
2.26.2

-- 
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/20210208062859.11429-2-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next RESEND 1/5] net: stmmac: dwmac-sun8i: Return void from PHY unpower

[Samuel Holland]

This is a deinitialization function that always returned zero, and that
return value was always ignored. Have it return void instead.

Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index a5e0eff4a387..8e505019adf8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -820,15 +820,14 @@ static int sun8i_dwmac_power_internal_phy(struct 
stmmac_priv *priv)
return 0;
 }
 
-static int sun8i_dwmac_unpower_internal_phy(struct sunxi_priv_data *gmac)
+static void sun8i_dwmac_unpower_internal_phy(struct sunxi_priv_data *gmac)
 {
if (!gmac->internal_phy_powered)
-   return 0;
+   return;
 
clk_disable_unprepare(gmac->ephy_clk);
reset_control_assert(gmac->rst_ephy);
gmac->internal_phy_powered = false;
-   return 0;
 }
 
 /* MDIO multiplexing switch function
-- 
2.26.2

-- 
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/20210208062859.11429-3-samuel%40sholland.org.

[linux-sunxi] Re: Fail to boot on bpim3 with next-20210128

[Samuel Holland]

On 1/30/21 11:00 AM, Corentin Labbe wrote:
> Hello
> 
> next-20210128 cannot be booted on my bpim3.
> It start booting then freeze.
> 
> [0.00] Linux version 5.11.0-rc5-03084-g7426957d237f (compile@Red) 
> (armv7a-unknown-linux-gnueabihf-gcc (Gentoo 9.3.0-r2 p4) 9.3.0, GNU ld 
> (Gentoo 2.34 p6) 2.34.0) #390 SMP Sat Jan 30 14:59:48 CET 2021
> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> [0.00] CPU: div instructions available: patching division code
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: Banana Pi BPI-M3
> [0.00] earlycon: uart0 at MMIO32 0x01c28000 (options '')
> [0.00] printk: bootconsole [uart0] enabled
> [0.00] Memory policy: Data cache writealloc
> [0.00] cma: Reserved 16 MiB at 0xbf00
> [0.00] Zone ranges:
> [0.00]   Normal   [mem 0x4000-0x6fff]
> [0.00]   HighMem  [mem 0x7000-0xbfff]
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x4000-0xbfff]
> [0.00] Initmem setup node 0 [mem 
> 0x4000-0xbfff]
> [0.00] percpu: Embedded 15 pages/cpu s31244 r8192 d22004 u61440
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 522752
> [0.00] Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 
> earlycon=uart,mmio32,0x01c28000 ip=dhcp
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes, linear)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, 
> linear)
> [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off
> [0.00] Memory: 2021376K/2097152K available (7168K kernel code, 934K 
> rwdata, 2316K rodata, 1024K init, 240K bss, 59392K reserved, 16384K 
> cma-reserved, 1294336K highmem)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
> [0.00] rcu: Hierarchical RCU implementation.
> [0.00] rcu:   RCU event tracing is enabled.
> [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 
> jiffies.
> [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [0.00] random: get_random_bytes called from start_kernel+0x350/0x4e0 
> with crng_init=0
> [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (virt).
> [0.00] clocksource: arch_sys_counter: mask: 0xff 
> max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
> [0.03] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 
> 4398046511097ns
> [0.008640] Switching to timer-based delay loop, resolution 41ns
> [0.015437] clocksource: timer: mask: 0x max_cycles: 0x, 
> max_idle_ns: 79635851949 ns
> [0.025858] Console: colour dummy device 80x30
> [0.030736] Calibrating delay loop (skipped), value calculated using timer 
> frequency.. 48.00 BogoMIPS (lpj=24)
> [0.041941] pid_max: default: 32768 minimum: 301
> [0.047080] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, 
> linear)
> [0.054990] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 
> bytes, linear)
> [0.064421] CPU: Testing write buffer coherency: ok
> [0.070242] /cpus/cpu@0 missing clock-frequency property
> [0.076025] /cpus/cpu@1 missing clock-frequency property
> [0.081805] /cpus/cpu@2 missing clock-frequency property
> [0.087546] /cpus/cpu@3 missing clock-frequency property
> [0.093300] /cpus/cpu@100 missing clock-frequency property
> [0.099227] /cpus/cpu@101 missing clock-frequency property
> [0.105173] /cpus/cpu@102 missing clock-frequency property
> [0.11] /cpus/cpu@103 missing clock-frequency property
> [0.117026] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
> [0.123888] Setting up static identity map for 0x4010 - 0x40100060
> [0.131237] ARM CCI driver probed
> [0.135530] sunxi multi cluster SMP support installed
> [0.141501] rcu: Hierarchical SRCU implementation.
> [0.147277] smp: Bringing up secondary CPUs ...
> [0.153237] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
> [0.154443] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
> [0.155544] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
> [0.156837] CPU4: thread -1, cpu 0, socket 1, mpidr 8100
> [0.158221] CPU5: thread -1, cpu 1, socket 1, mpidr 8101
> [0.159456] CPU6: thread -1, cpu 2, socket 1, mpidr 8102
> [0.160663] CPU7: thread -1, cpu 3, socket 1, mpidr 8103
> [0.160825] smp: Brought up 1 node, 8 CPUs
> [0.207953] SMP: Total of 8 processors activated (384.00 BogoMIPS).
> [0.214714] CPU: All CPU(s) started in SVC mode.
> [0.221355] devtmpfs: initialized
> [0.232737] VFP support v0.3: implementor 41 architecture 2 part 

Re: [linux-sunxi] Re: [PATCH v2 05/21] sunxi: prcm: Add memory map for H6 like SoCs

[Samuel Holland]

On 1/21/21 7:14 PM, Andre Przywara wrote:
> On Mon, 11 Jan 2021 21:11:37 +0100
> Jernej Skrabec  wrote:
> 
>> There was no need to have prcm definitions for H6 and similar SoCs till
>> now. However, support R_I2C will be needed soon in SPL.
>>
>> Move old definitions to prcm_sun6i.h and add new ones in prcm_sun50i.h.
>> One of those files will be selected in common prcm.h based on defined
>> macros.
>>
>> This commit doesn't do any functional change.
> 
> That looks alright.
> prcm.h and prcm_sun6i.h are identical, apart from the header guards.
> I could verify most of the sun50i PRCM fields by comparing to the Linux
> CCU_R driver, but not all of them.
> Out of curiosity, where do those offsets actually come from? Some BSP
> code? And they are actually SUN50I_H6 aka. "NCAT" specific, right?

Compare:

https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/clk/sunxi/clk-sun50iw6.h#L148

https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/clk/sunxi/clk-sun50iw9.h#L158

(This, and experimentation, is also where my "0x20c is the highest
clock-gate-related register" comment on the DTS came from).

Cheers,
Samuel

-- 
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/4af0a4de-2cd7-878b-2bc7-662bcdee744b%40sholland.org.

[linux-sunxi] Re: [PATCH v2 16/21] sunxi: Add H616 FEL support

[Samuel Holland]

On 1/11/21 2:11 PM, Jernej Skrabec wrote:
> H616 uses different address for reset. Add it.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/cpu/armv8/fel_utils.S | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
> index 9510dcd9e4c1..2dbd4b365221 100644
> --- a/arch/arm/cpu/armv8/fel_utils.S
> +++ b/arch/arm/cpu/armv8/fel_utils.S
> @@ -40,7 +40,10 @@ ENTRY(return_to_fel)
>   str w2, [x1]
>  
>   ldr x0, =0xfa50392f // CPU hotplug magic
> -#ifdef CONFIG_MACH_SUN50I_H6
> +#ifdef CONFIG_MACH_SUN50I_H616
> + ldr x2, =(SUNXI_RTC_BASE + 0x5c0)

This is more accurately (SUNXI_R_CPUCFG_BASE + 0x1c0).

This is noticeable in secure mode, where the RTC is accessible but
R_CPUCFG is not.

Cheers,
Samuel

> + str w0, [x2], #0x4
> +#elif CONFIG_MACH_SUN50I_H6
>   ldr x2, =(SUNXI_RTC_BASE + 0x1b8)   // BOOT_CPU_HP_FLAG_REG
>   str w0, [x2], #0x4
>  #else
> 

-- 
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/e6e66ec1-888d-6089-2b76-1b68d0374bf3%40sholland.org.

[linux-sunxi] [RFC PATCH 0/2] sunxi: Pass a reboot mode to the bootloader via the RTC

[Samuel Holland]

As the A64 is designed for use in mobile devices without easy access to
a UART, MMC0, or a FEL button, it would be useful to be able to reboot
to FEL mode, fastboot, etc. via a command from Linux. As reboot(2)
supports passing a command with LINUX_REBOOT_CMD_RESTART2, and we have
battery-backed RAM provided by the RTC (and also the PMIC), we can hook
the Linux side up with just a little bit of glue.

For examples of the bootloader side, see Rockchip boards in U-Boot[1]
(an implementation of this for a similar platform) and p-boot[2] (an
implementation of a similar idea for the A64). An interesting feature of
the p-boot implementation is the ability to choose and chainload the
bootloader from a different storage medium. This allows modifying the
boot order without needing to burn eFuses.

I'm sending this as an RFC to start discussion about allocating these
RTC registers, for this and other purposes. p-boot uses a second
register to store a boot order and some flags[3]. There has also been
discussion of using the registers to store key material and a
tamper-evident boot shim, to make up for deficiencies in the SoC's
secure boot ROM.

I suggest putting the reboot mode at the beginning of the region (to
preserve the most consecutive registers for other uses), or copying
p-boot's layout and using the second register (to respect prior art).

Consecutive values (like the Allwinner[4] and Rockchip implementations)
or arbitrary values (like in patch 2) would work for the reboot mode.
I would suggest magic numbers with higher entropy than those in p-boot.

Any ideas/comments are welcome.

Cheers,
Samuel

[1]: https://lists.denx.de/pipermail/u-boot/2016-September/267128.html
[2]: 
https://megous.com/git/p-boot/commit/?id=5ebcf9d7f611d87eac16e06ab7f77f679c593d07
[3]: https://megous.com/git/p-boot/tree/src/main.c#n144
[4]: 
https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/rtc/rtc-sunxi.h#L113

Samuel Holland (2):
  rtc: sun6i: Add NVMEM provider
  arm64: dts: allwinner: a64: Add reboot mode

 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 17 
 drivers/rtc/rtc-sun6i.c   | 42 +++
 2 files changed, 59 insertions(+)

-- 
2.26.2

-- 
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/20210119055204.55070-1-samuel%40sholland.org.

[linux-sunxi] [RFC PATCH 2/2] arm64: dts: allwinner: a64: Add reboot mode

[Samuel Holland]

Store a reboot mode in one of the RTC's general purpose registers.
This value can be used by U-Boot or another bootlader, for example to
enter FEL or fastboot mode.

Signed-off-by: Samuel Holland 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 5dfa9b5e7ee3..9891ee996794 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -155,6 +155,17 @@ psci {
method = "smc";
};
 
+   reboot-mode {
+   compatible = "nvmem-reboot-mode";
+   nvmem-cells = <_mode>;
+   nvmem-cell-names = "reboot-mode";
+
+   mode-normal = <0x0>;
+   mode-bootloader = <0xfa57b007>;
+   mode-fel= <0xe1fe1fe1>;
+   mode-ums= <0x05704a6e>;
+   };
+
scpi_protocol: scpi {
compatible = "arm,scpi";
mboxes = < 2>, < 3>;
@@ -1283,6 +1294,12 @@ rtc: rtc@1f0 {
clock-output-names = "osc32k", "osc32k-out", "iosc";
clocks = <>;
#clock-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   reboot_mode: reboot-mode@0 {
+   reg = <0x0 0x4>;
+   };
};
 
r_intc: interrupt-controller@1f00c00 {
-- 
2.26.2

-- 
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/20210119055204.55070-3-samuel%40sholland.org.

[linux-sunxi] [RFC PATCH 1/2] rtc: sun6i: Add NVMEM provider

[Samuel Holland]

The sun6i RTC provides 64 bytes of general-purpose data registers.
They can be used to save data in the always-on RTC power domain.
The registers are writable via 32-bit MMIO accesses only.

Expose the region as a NVMEM provider so it can be used by userspace and
other drivers.

Signed-off-by: Samuel Holland 
---
 drivers/rtc/rtc-sun6i.c | 42 +
 1 file changed, 42 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index e75020ab8024..d9d381adc62a 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -69,6 +69,10 @@
 #define SUN6I_LOSC_OUT_GATING  0x0060
 #define SUN6I_LOSC_OUT_GATING_EN_OFFSET0
 
+/* Battery-backed general-purpose SRAM */
+#define SUN6I_GP_DATA  0x0100
+#define SUN6I_GP_DATA_SIZE 0x40
+
 /*
  * Get date values
  */
@@ -641,6 +645,39 @@ static const struct rtc_class_ops sun6i_rtc_ops = {
.alarm_irq_enable   = sun6i_rtc_alarm_irq_enable
 };
 
+static int sun6i_rtc_nvmem_read(void *priv, unsigned int offset, void *_val, 
size_t bytes)
+{
+   struct sun6i_rtc_dev *chip = priv;
+   u32 *val = _val;
+   int i;
+
+   for (i = 0; i < bytes / 4; ++i)
+   val[i] = readl(chip->base + SUN6I_GP_DATA + offset + 4 * i);
+
+   return 0;
+}
+
+static int sun6i_rtc_nvmem_write(void *priv, unsigned int offset, void *_val, 
size_t bytes)
+{
+   struct sun6i_rtc_dev *chip = priv;
+   u32 *val = _val;
+   int i;
+
+   for (i = 0; i < bytes / 4; ++i)
+   writel(val[i], chip->base + SUN6I_GP_DATA + offset + 4 * i);
+
+   return 0;
+}
+
+static struct nvmem_config sun6i_rtc_nvmem_cfg = {
+   .type   = NVMEM_TYPE_BATTERY_BACKED,
+   .reg_read   = sun6i_rtc_nvmem_read,
+   .reg_write  = sun6i_rtc_nvmem_write,
+   .size   = SUN6I_GP_DATA_SIZE,
+   .word_size  = 4,
+   .stride = 4,
+};
+
 /* Enable IRQ wake on suspend, to wake up from RTC. */
 static int sun6i_rtc_suspend(struct device *dev)
 {
@@ -728,6 +765,11 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   sun6i_rtc_nvmem_cfg.priv = chip;
+   ret = devm_rtc_nvmem_register(chip->rtc, _rtc_nvmem_cfg);
+   if (ret)
+   return ret;
+
dev_info(>dev, "RTC enabled\n");
 
return 0;
-- 
2.26.2

-- 
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/20210119055204.55070-2-samuel%40sholland.org.

Re: [linux-sunxi] [PATCH] sunxi: Properly check for SATAPWR and MACPWR

[Samuel Holland]

On 1/18/21 7:05 PM, Andre Przywara wrote:
> The #ifdef CONFIG_xxxPWR conditionals were not working as expected, as
> string Kconfig symbols are always "defined" from the preprocessor's
> perspective. This lead to unnecessary calls to the GPIO routines, but
> also always added a half a second delay to wait for a SATA disk to power
> up. Many thanks to Peter for pointing this out!
> 
> Fix this by properly comparing the Kconfig symbols against the empty
> string. strcmp() would be nicer for this, but GCC does not optimise this
> away, probably due to our standalone compiler switches.

Ethernet still works, and the speed-up is welcome.

Tested-by: Samuel Holland  # Orange Pi WinPlus

Cheers,
Samuel

-- 
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/40813da5-ab8c-4d62-b3ec-c2199bc5e313%40sholland.org.

[linux-sunxi] Re: [PATCH v2 0/4] media: sunxi-cir: Cleanup and power management

[Samuel Holland]

On 1/18/21 12:00 AM, Samuel Holland wrote:
> This series cleans up some dead code in the sunxi-cir driver and adds
> system power management hooks.
> 
> ---
> Changes from v1:
>   - Unregister the RC device first thing in sunxi_ir_remove() [3]

I forgot to add:

Acked-by: Maxime Ripard 

from v1.

> Samuel Holland (4):
>   media: sunxi-cir: Clean up dead register writes
>   media: sunxi-cir: Remove unnecessary spinlock
>   media: sunxi-cir: Factor out hardware initialization
>   media: sunxi-cir: Implement suspend/resume/shutdown callbacks
> 
>  drivers/media/rc/sunxi-cir.c | 169 ---
>  1 file changed, 95 insertions(+), 74 deletions(-)
> 

-- 
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/60db28fd-928e-a735-d6ef-6c6cd04bb289%40sholland.org.

[linux-sunxi] [PATCH v2 4/4] media: sunxi-cir: Implement suspend/resume/shutdown callbacks

[Samuel Holland]

To save power, gate/reset the hardware block while the system is
asleep or powered off.

Signed-off-by: Samuel Holland 
---
 drivers/media/rc/sunxi-cir.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 2d099da8d3cc..168e1d2c876a 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -234,6 +234,20 @@ static void sunxi_ir_hw_exit(struct device *dev)
reset_control_assert(ir->rst);
 }
 
+static int __maybe_unused sunxi_ir_suspend(struct device *dev)
+{
+   sunxi_ir_hw_exit(dev);
+
+   return 0;
+}
+
+static int __maybe_unused sunxi_ir_resume(struct device *dev)
+{
+   return sunxi_ir_hw_init(dev);
+}
+
+static SIMPLE_DEV_PM_OPS(sunxi_ir_pm_ops, sunxi_ir_suspend, sunxi_ir_resume);
+
 static int sunxi_ir_probe(struct platform_device *pdev)
 {
int ret = 0;
@@ -362,6 +376,11 @@ static int sunxi_ir_remove(struct platform_device *pdev)
return 0;
 }
 
+static void sunxi_ir_shutdown(struct platform_device *pdev)
+{
+   sunxi_ir_hw_exit(>dev);
+}
+
 static const struct sunxi_ir_quirks sun4i_a10_ir_quirks = {
.has_reset = false,
.fifo_size = 16,
@@ -397,9 +416,11 @@ MODULE_DEVICE_TABLE(of, sunxi_ir_match);
 static struct platform_driver sunxi_ir_driver = {
.probe  = sunxi_ir_probe,
.remove = sunxi_ir_remove,
+   .shutdown   = sunxi_ir_shutdown,
.driver = {
.name = SUNXI_IR_DEV,
.of_match_table = sunxi_ir_match,
+   .pm = _ir_pm_ops,
},
 };
 
-- 
2.26.2

-- 
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/20210118060048.22267-5-samuel%40sholland.org.

[linux-sunxi] [PATCH v2 2/4] media: sunxi-cir: Remove unnecessary spinlock

[Samuel Holland]

Only one register, SUNXI_IR_CIR_REG, is accessed from outside the
interrupt handler, and that register is not accessed from inside it.
As there is no overlap between different contexts, no lock is needed.

Signed-off-by: Samuel Holland 
---
 drivers/media/rc/sunxi-cir.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 0a7f7eab3cc3..48be400421cd 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -86,7 +86,6 @@ struct sunxi_ir_quirks {
 };
 
 struct sunxi_ir {
-   spinlock_t  ir_lock;
struct rc_dev   *rc;
void __iomem*base;
int irq;
@@ -105,8 +104,6 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
struct sunxi_ir *ir = dev_id;
struct ir_raw_event rawir = {};
 
-   spin_lock(>ir_lock);
-
status = readl(ir->base + SUNXI_IR_RXSTA_REG);
 
/* clean all pending statuses */
@@ -137,8 +134,6 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
ir_raw_event_handle(ir->rc);
}
 
-   spin_unlock(>ir_lock);
-
return IRQ_HANDLED;
 }
 
@@ -160,17 +155,14 @@ static int sunxi_ir_set_timeout(struct rc_dev *rc_dev, 
unsigned int timeout)
 {
struct sunxi_ir *ir = rc_dev->priv;
unsigned int base_clk = clk_get_rate(ir->clk);
-   unsigned long flags;
 
unsigned int ithr = sunxi_usec_to_ithr(base_clk, timeout);
 
dev_dbg(rc_dev->dev.parent, "setting idle threshold to %u\n", ithr);
 
-   spin_lock_irqsave(>ir_lock, flags);
/* Set noise threshold and idle threshold */
writel(REG_CIR_NTHR(SUNXI_IR_RXNOISE) | REG_CIR_ITHR(ithr),
   ir->base + SUNXI_IR_CIR_REG);
-   spin_unlock_irqrestore(>ir_lock, flags);
 
rc_dev->timeout = sunxi_ithr_to_usec(base_clk, ithr);
 
@@ -199,8 +191,6 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   spin_lock_init(>ir_lock);
-
ir->fifo_size = quirks->fifo_size;
 
/* Clock */
-- 
2.26.2

-- 
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/20210118060048.22267-3-samuel%40sholland.org.

[linux-sunxi] [PATCH v2 3/4] media: sunxi-cir: Factor out hardware initialization

[Samuel Holland]

In preparation for adding suspend/resume hooks, factor out the hardware
initialization from the driver probe/remove functions.

The timeout programmed during init is taken from the `struct rc_dev` so
it is maintained across an exit/init cycle.

This resolves some trivial issues with the probe function: throwing away
the error from clk_prepare_enable and using the wrong type for the
temporary register value.

It also fixes the order of the remove function to unregister the RC
device before turning off the hardware. This prevents userspace from
triggering register writes (via LIRC_SET_REC_TIMEOUT) while the hardware
is disabled.

Signed-off-by: Samuel Holland 
---
 drivers/media/rc/sunxi-cir.c | 128 ---
 1 file changed, 74 insertions(+), 54 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 48be400421cd..2d099da8d3cc 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -169,10 +169,74 @@ static int sunxi_ir_set_timeout(struct rc_dev *rc_dev, 
unsigned int timeout)
return 0;
 }
 
+static int sunxi_ir_hw_init(struct device *dev)
+{
+   struct sunxi_ir *ir = dev_get_drvdata(dev);
+   u32 tmp;
+   int ret;
+
+   ret = reset_control_deassert(ir->rst);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(ir->apb_clk);
+   if (ret) {
+   dev_err(dev, "failed to enable apb clk\n");
+   goto exit_assert_reset;
+   }
+
+   ret = clk_prepare_enable(ir->clk);
+   if (ret) {
+   dev_err(dev, "failed to enable ir clk\n");
+   goto exit_disable_apb_clk;
+   }
+
+   /* Enable CIR Mode */
+   writel(REG_CTL_MD, ir->base + SUNXI_IR_CTL_REG);
+
+   /* Set noise threshold and idle threshold */
+   sunxi_ir_set_timeout(ir->rc, ir->rc->timeout);
+
+   /* Invert Input Signal */
+   writel(REG_RXCTL_RPPI, ir->base + SUNXI_IR_RXCTL_REG);
+
+   /* Clear All Rx Interrupt Status */
+   writel(REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
+
+   /*
+* Enable IRQ on overflow, packet end, FIFO available with trigger
+* level
+*/
+   writel(REG_RXINT_ROI_EN | REG_RXINT_RPEI_EN |
+  REG_RXINT_RAI_EN | REG_RXINT_RAL(ir->fifo_size / 2 - 1),
+  ir->base + SUNXI_IR_RXINT_REG);
+
+   /* Enable IR Module */
+   tmp = readl(ir->base + SUNXI_IR_CTL_REG);
+   writel(tmp | REG_CTL_GEN | REG_CTL_RXEN, ir->base + SUNXI_IR_CTL_REG);
+
+   return 0;
+
+exit_disable_apb_clk:
+   clk_disable_unprepare(ir->apb_clk);
+exit_assert_reset:
+   reset_control_assert(ir->rst);
+
+   return ret;
+}
+
+static void sunxi_ir_hw_exit(struct device *dev)
+{
+   struct sunxi_ir *ir = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(ir->clk);
+   clk_disable_unprepare(ir->apb_clk);
+   reset_control_assert(ir->rst);
+}
+
 static int sunxi_ir_probe(struct platform_device *pdev)
 {
int ret = 0;
-   unsigned long tmp = 0;
 
struct device *dev = >dev;
struct device_node *dn = dev->of_node;
@@ -213,43 +277,26 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rst = devm_reset_control_get_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
return PTR_ERR(ir->rst);
-   ret = reset_control_deassert(ir->rst);
-   if (ret)
-   return ret;
}
 
ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
-   goto exit_reset_assert;
+   return ret;
}
dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
 
-   if (clk_prepare_enable(ir->apb_clk)) {
-   dev_err(dev, "try to enable apb_ir_clk failed\n");
-   ret = -EINVAL;
-   goto exit_reset_assert;
-   }
-
-   if (clk_prepare_enable(ir->clk)) {
-   dev_err(dev, "try to enable ir_clk failed\n");
-   ret = -EINVAL;
-   goto exit_clkdisable_apb_clk;
-   }
-
/* IO */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ir->base = devm_ioremap_resource(dev, res);
if (IS_ERR(ir->base)) {
-   ret = PTR_ERR(ir->base);
-   goto exit_clkdisable_clk;
+   return PTR_ERR(ir->base);
}
 
ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir->rc) {
dev_err(dev, "failed to allocate device\n");
-   ret = -ENOMEM;
-   goto exit_clkdisable_clk;
+   return -ENOMEM;
}
 
ir->rc->priv = ir;
@@ -265,6 +312,7 @@ static int sunxi_

[linux-sunxi] [PATCH v2 1/4] media: sunxi-cir: Clean up dead register writes

[Samuel Holland]

The register writes during driver removal occur after the device is
already put back in reset, so they never had any effect.

Signed-off-by: Samuel Holland 
---
 drivers/media/rc/sunxi-cir.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 8555c7798706..0a7f7eab3cc3 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -342,22 +342,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
 
 static int sunxi_ir_remove(struct platform_device *pdev)
 {
-   unsigned long flags;
struct sunxi_ir *ir = platform_get_drvdata(pdev);
 
clk_disable_unprepare(ir->clk);
clk_disable_unprepare(ir->apb_clk);
reset_control_assert(ir->rst);
 
-   spin_lock_irqsave(>ir_lock, flags);
-   /* disable IR IRQ */
-   writel(0, ir->base + SUNXI_IR_RXINT_REG);
-   /* clear All Rx Interrupt Status */
-   writel(REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
-   /* disable IR */
-   writel(0, ir->base + SUNXI_IR_CTL_REG);
-   spin_unlock_irqrestore(>ir_lock, flags);
-
rc_unregister_device(ir->rc);
return 0;
 }
-- 
2.26.2

-- 
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/20210118060048.22267-2-samuel%40sholland.org.

[linux-sunxi] [PATCH v2 0/4] media: sunxi-cir: Cleanup and power management

[Samuel Holland]

This series cleans up some dead code in the sunxi-cir driver and adds
system power management hooks.

---
Changes from v1:
  - Unregister the RC device first thing in sunxi_ir_remove() [3]

Samuel Holland (4):
  media: sunxi-cir: Clean up dead register writes
  media: sunxi-cir: Remove unnecessary spinlock
  media: sunxi-cir: Factor out hardware initialization
  media: sunxi-cir: Implement suspend/resume/shutdown callbacks

 drivers/media/rc/sunxi-cir.c | 169 ---
 1 file changed, 95 insertions(+), 74 deletions(-)

-- 
2.26.2

-- 
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/20210118060048.22267-1-samuel%40sholland.org.

[linux-sunxi] Re: [PATCH v3 19/21] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Samuel Holland]

On 1/17/21 8:08 PM, 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 extra interrupt controller anymore, also
> it lacks the corresponding NMI pin, so no interrupts for the PMIC.
> 
> Signed-off-by: Andre Przywara 
> ---
>  .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 750 ++
>  1 file changed, 750 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 ..953e8fac20f0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -0,0 +1,750 @@
> +// 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 = <>;
> + #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 = < CLK_CPUX>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + clocks = < CLK_CPUX>;
> + };
> +
> + cpu2: cpu@2 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + clocks = < CLK_CPUX>;
> + };
> +
> + cpu3: cpu@3 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + clocks = < 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;
> + };
> + };
> +
> + 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 = <>, <>, <>, <>;
> + };
> +
> + 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)>,
> +   + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x4000>;
> +
> + syscon: syscon@300 {
> + compatible = "allwinner,sun50i-h616-system-control";
> + reg = <0x0300 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram_c: sram@28000 {
> + compatible = "mmio-sram";
> + reg = <0x00028000 0x3>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x00028000 0x3>;
> + };
> + };
> +
> + ccu: clock@3001000 {
> + compatible = "allwinner,sun50i-h616-ccu";
> + reg = <0x03001000 0x1000>;
> 

[linux-sunxi] Re: [PATCH v3 18/21] dt-bindings: allwinner: Add H616 compatible strings

[Samuel Holland]

On 1/17/21 8:08 PM, Andre Przywara wrote:
> Add simple "allwinner,sun50i-h616-xxx" compatible names to existing
> bindings, and pair them with an existing fallback compatible string,
> as the devices are compatible.
> This covers I2C, infrared, RTC and SPI.
> 
> Use enums to group all compatible devices together.
> 
> Signed-off-by: Andre Przywara 
> Acked-by: Rob Herring 
> Acked-by: Wolfram Sang  # for I2C
> ---
>  .../bindings/i2c/marvell,mv64xxx-i2c.yaml | 21 +++
>  .../media/allwinner,sun4i-a10-ir.yaml | 16 ++
>  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml |  3 +++
>  .../bindings/spi/allwinner,sun6i-a31-spi.yaml |  1 +
>  4 files changed, 17 insertions(+), 24 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml 
> b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
> index 5b5ae402f97a..eb72dd571def 100644
> --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
> @@ -18,21 +18,14 @@ properties:
>- const: allwinner,sun4i-a10-i2c
>- const: allwinner,sun6i-a31-i2c
>- items:
> -  - const: allwinner,sun8i-a23-i2c
> +  - enum:
> +  - allwinner,sun8i-a23-i2c
> +  - allwinner,sun8i-a83t-i2c
> +  - allwinner,sun50i-a64-i2c
> +  - allwinner,sun50i-a100-i2c
> +  - allwinner,sun50i-h6-i2c
> +  - allwinner,sun50i-h616-i2c
>- const: allwinner,sun6i-a31-i2c
> -  - items:
> -  - const: allwinner,sun8i-a83t-i2c
> -  - const: allwinner,sun6i-a31-i2c
> -  - items:
> -  - const: allwinner,sun50i-a64-i2c
> -  - const: allwinner,sun6i-a31-i2c
> -  - items:
> -  - const: allwinner,sun50i-a100-i2c
> -  - const: allwinner,sun6i-a31-i2c
> -  - items:
> -  - const: allwinner,sun50i-h6-i2c
> -  - const: allwinner,sun6i-a31-i2c
> -
>- const: marvell,mv64xxx-i2c
>- const: marvell,mv78230-i2c
>- const: marvell,mv78230-a0-i2c
> diff --git 
> a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml 
> b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
> index 5fa19d4aeaf3..6d8395d6bca0 100644
> --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
> +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml
> @@ -20,16 +20,12 @@ properties:
>- const: allwinner,sun5i-a13-ir
>- const: allwinner,sun6i-a31-ir
>- items:
> -  - const: allwinner,sun8i-a83t-ir
> -  - const: allwinner,sun6i-a31-ir
> -  - items:
> -  - const: allwinner,sun8i-r40-ir
> -  - const: allwinner,sun6i-a31-ir
> -  - items:
> -  - const: allwinner,sun50i-a64-ir
> -  - const: allwinner,sun6i-a31-ir
> -  - items:
> -  - const: allwinner,sun50i-h6-ir
> +  - enum:
> +  - allwinner,sun8i-a83t-ir
> +  - allwinner,sun8i-r40-ir
> +  - allwinner,sun50i-a64-ir
> +  - allwinner,sun50i-h6-ir
> +  - allwinner,sun50i-h616-ir
>- const: allwinner,sun6i-a31-ir
>  
>reg:
> diff --git 
> a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
> b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> index 37c2a601c3fa..97928efd2bc9 100644
> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> @@ -26,6 +26,9 @@ properties:
>- const: allwinner,sun50i-a64-rtc
>- const: allwinner,sun8i-h3-rtc
>- const: allwinner,sun50i-h6-rtc
> +  - items:
> +  - const: allwinner,sun50i-h616-rtc
> +  - const: allwinner,sun50i-h6-rtc

Since H6, the RTC manages the 24 MHz DCXO, so it provides a fourth clock
output. If this is easy to change later, then it is fine for now, but
maybe it is better to get the H616 binding correct from the beginning?

Cheers,
Samuel

>reg:
>  maxItems: 1
> diff --git 
> a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml 
> b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
> index 7866a655d81c..908248260afa 100644
> --- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
> +++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
> @@ -25,6 +25,7 @@ properties:
>- enum:
>- allwinner,sun8i-r40-spi
>- allwinner,sun50i-h6-spi
> +  - allwinner,sun50i-h616-spi
>- const: allwinner,sun8i-h3-spi
>  
>reg:
> 

-- 
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] Re: [PATCH v3 09/21] mfd: axp20x: Allow AXP chips without interrupt lines

[Samuel Holland]

On 1/17/21 8:08 PM, Andre Przywara wrote:
> Currently the AXP chip requires to have its IRQ line connected to some
> interrupt controller, and will fail probing when this is not the case.
> 
> On a new Allwinner SoC (H616) there is no NMI pin anymore, so the
> interrupt functionality of the AXP chip is simply not available.
> 
> Check whether the DT describes the AXP chip as an interrupt controller
> before trying to register the irqchip, to avoid probe failures on
> setups without an interrupt.

The AXP305 has an IRQ pin. It is still an interrupt controller, even if
its output is not connected anywhere. And even though the NMI pin on the
H616 is gone, the PMIC IRQ line could be connected to a GPIO. So it is
not appropriate to remove "interrupt-controller".

Per the binding, both "interrupts" and "interrupt-controller" are
required properties. It would make more sense to make "interrupts"
optional. Either way, you need to update the binding.

Though I'm concerned about how this may affect drivers for regmap cells
which use interrupts (such as axp20x-pek). If the irqchip is not
registered, requesting those interrupts will fail. While I don't
currently know of any boards that have the AXP305 power key wired up, it
prevents us from modelling the hardware correctly and supporting that
configuration.

Cheers,
Samuel

> Signed-off-by: Andre Przywara 
> ---
>  drivers/mfd/axp20x.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index aa59496e4376..a52595c49d40 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -959,12 +959,17 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
>AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE);
>   }
>  
> - ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
> -   IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
> --1, axp20x->regmap_irq_chip, >regmap_irqc);
> - if (ret) {
> - dev_err(axp20x->dev, "failed to add irq chip: %d\n", ret);
> - return ret;
> + if (!axp20x->dev->of_node ||
> + of_property_read_bool(axp20x->dev->of_node, 
> "interrupt-controller")) {
> + ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
> + IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
> + -1, axp20x->regmap_irq_chip,
> + >regmap_irqc);
> + if (ret) {
> + dev_err(axp20x->dev, "failed to add irq chip: %d\n",
> + ret);
> + return ret;
> + }
>   }
>  
>   ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
> 

-- 
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/b3d1cc46-3311-ba1a-f71a-37096ed1bfa8%40sholland.org.

[linux-sunxi] Re: [PATCH 3/4] media: sunxi-cir: Factor out hardware initialization

[Samuel Holland]

On 1/13/21 8:36 AM, Sean Young wrote:
> On Tue, Jan 12, 2021 at 10:51:31PM -0600, Samuel Holland wrote:
>> In preparation for adding suspend/resume hooks, factor out the hardware
>> initialization from the driver probe/remove functions.
>>
>> The timeout programmed during init is taken from the `struct rc_dev` so
>> it is maintained across an exit/init cycle.
>>
>> This resolves some trivial issues with the probe function: throwing away
>> the error from clk_prepare_enable and using the wrong type for the
>> temporary register value.
>>
>> Signed-off-by: Samuel Holland 
>> ---
>>  drivers/media/rc/sunxi-cir.c | 128 ---
>>  1 file changed, 74 insertions(+), 54 deletions(-)
>>
>> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
>> index 48be400421cd..ccb9d6b4225d 100644
>> --- a/drivers/media/rc/sunxi-cir.c
>> +++ b/drivers/media/rc/sunxi-cir.c
>> @@ -169,10 +169,74 @@ static int sunxi_ir_set_timeout(struct rc_dev *rc_dev, 
>> unsigned int timeout)
>>  return 0;
>>  }
>>  
>> +static int sunxi_ir_hw_init(struct device *dev)
>> +{
>> +struct sunxi_ir *ir = dev_get_drvdata(dev);
>> +u32 tmp;
>> +int ret;
>> +
>> +ret = reset_control_deassert(ir->rst);
>> +if (ret)
>> +return ret;
>> +
>> +ret = clk_prepare_enable(ir->apb_clk);
>> +if (ret) {
>> +dev_err(dev, "failed to enable apb clk\n");
>> +goto exit_assert_reset;
>> +}
>> +
>> +ret = clk_prepare_enable(ir->clk);
>> +if (ret) {
>> +dev_err(dev, "failed to enable ir clk\n");
>> +goto exit_disable_apb_clk;
>> +}
>> +
>> +/* Enable CIR Mode */
>> +writel(REG_CTL_MD, ir->base + SUNXI_IR_CTL_REG);
>> +
>> +/* Set noise threshold and idle threshold */
>> +sunxi_ir_set_timeout(ir->rc, ir->rc->timeout);

Initializing ir->rc->timeout in .probe is needed because of this line.
As the changelog mentions, this reprograms the user-configured timeout
after an exit/init (suspend/resume) cycle. It needs some default value
the first time, when called from .probe.

>> +
>> +/* Invert Input Signal */
>> +writel(REG_RXCTL_RPPI, ir->base + SUNXI_IR_RXCTL_REG);
>> +
>> +/* Clear All Rx Interrupt Status */
>> +writel(REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
>> +
>> +/*
>> + * Enable IRQ on overflow, packet end, FIFO available with trigger
>> + * level
>> + */
>> +writel(REG_RXINT_ROI_EN | REG_RXINT_RPEI_EN |
>> +   REG_RXINT_RAI_EN | REG_RXINT_RAL(ir->fifo_size / 2 - 1),
>> +   ir->base + SUNXI_IR_RXINT_REG);
>> +
>> +/* Enable IR Module */
>> +tmp = readl(ir->base + SUNXI_IR_CTL_REG);
>> +writel(tmp | REG_CTL_GEN | REG_CTL_RXEN, ir->base + SUNXI_IR_CTL_REG);
>> +
>> +return 0;
>> +
>> +exit_disable_apb_clk:
>> +clk_disable_unprepare(ir->apb_clk);
>> +exit_assert_reset:
>> +reset_control_assert(ir->rst);
>> +
>> +return ret;
>> +}
>> +
>> +static void sunxi_ir_hw_exit(struct device *dev)
>> +{
>> +struct sunxi_ir *ir = dev_get_drvdata(dev);
>> +
>> +clk_disable_unprepare(ir->clk);
>> +clk_disable_unprepare(ir->apb_clk);
>> +reset_control_assert(ir->rst);
>> +}
>> +
>>  static int sunxi_ir_probe(struct platform_device *pdev)
>>  {
>>  int ret = 0;
>> -unsigned long tmp = 0;
>>  
>>  struct device *dev = >dev;
>>  struct device_node *dn = dev->of_node;
>> @@ -213,43 +277,26 @@ static int sunxi_ir_probe(struct platform_device *pdev)
>>  ir->rst = devm_reset_control_get_exclusive(dev, NULL);
>>  if (IS_ERR(ir->rst))
>>  return PTR_ERR(ir->rst);
>> -ret = reset_control_deassert(ir->rst);
>> -if (ret)
>> -return ret;
>>  }
>>  
>>  ret = clk_set_rate(ir->clk, b_clk_freq);
>>  if (ret) {
>>  dev_err(dev, "set ir base clock failed!\n");
>> -goto exit_reset_assert;
>> +return ret;
>>  }
>>  dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
>>  
>> -if (clk_prepare_enable(ir->apb_clk)) {
>> -dev_err(dev

[linux-sunxi] [PATCH 4/4] media: sunxi-cir: Implement suspend/resume/shutdown callbacks

[Samuel Holland]

To save power, gate/reset the hardware block while the system is
asleep or powered off.

Signed-off-by: Samuel Holland 
---
 drivers/media/rc/sunxi-cir.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index ccb9d6b4225d..a0bdbf6f66c9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -234,6 +234,20 @@ static void sunxi_ir_hw_exit(struct device *dev)
reset_control_assert(ir->rst);
 }
 
+static int __maybe_unused sunxi_ir_suspend(struct device *dev)
+{
+   sunxi_ir_hw_exit(dev);
+
+   return 0;
+}
+
+static int __maybe_unused sunxi_ir_resume(struct device *dev)
+{
+   return sunxi_ir_hw_init(dev);
+}
+
+static SIMPLE_DEV_PM_OPS(sunxi_ir_pm_ops, sunxi_ir_suspend, sunxi_ir_resume);
+
 static int sunxi_ir_probe(struct platform_device *pdev)
 {
int ret = 0;
@@ -362,6 +376,11 @@ static int sunxi_ir_remove(struct platform_device *pdev)
return 0;
 }
 
+static void sunxi_ir_shutdown(struct platform_device *pdev)
+{
+   sunxi_ir_hw_exit(>dev);
+}
+
 static const struct sunxi_ir_quirks sun4i_a10_ir_quirks = {
.has_reset = false,
.fifo_size = 16,
@@ -397,9 +416,11 @@ MODULE_DEVICE_TABLE(of, sunxi_ir_match);
 static struct platform_driver sunxi_ir_driver = {
.probe  = sunxi_ir_probe,
.remove = sunxi_ir_remove,
+   .shutdown   = sunxi_ir_shutdown,
.driver = {
.name = SUNXI_IR_DEV,
.of_match_table = sunxi_ir_match,
+   .pm = _ir_pm_ops,
},
 };
 
-- 
2.26.2

-- 
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/20210113045132.31430-5-samuel%40sholland.org.

[linux-sunxi] [PATCH 2/4] media: sunxi-cir: Remove unnecessary spinlock

[Samuel Holland]

Only one register, SUNXI_IR_CIR_REG, is accessed from outside the
interrupt handler, and that register is not accessed from inside it.
As there is no overlap between different contexts, no lock is needed.

Signed-off-by: Samuel Holland 
---
 drivers/media/rc/sunxi-cir.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 0a7f7eab3cc3..48be400421cd 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -86,7 +86,6 @@ struct sunxi_ir_quirks {
 };
 
 struct sunxi_ir {
-   spinlock_t  ir_lock;
struct rc_dev   *rc;
void __iomem*base;
int irq;
@@ -105,8 +104,6 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
struct sunxi_ir *ir = dev_id;
struct ir_raw_event rawir = {};
 
-   spin_lock(>ir_lock);
-
status = readl(ir->base + SUNXI_IR_RXSTA_REG);
 
/* clean all pending statuses */
@@ -137,8 +134,6 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
ir_raw_event_handle(ir->rc);
}
 
-   spin_unlock(>ir_lock);
-
return IRQ_HANDLED;
 }
 
@@ -160,17 +155,14 @@ static int sunxi_ir_set_timeout(struct rc_dev *rc_dev, 
unsigned int timeout)
 {
struct sunxi_ir *ir = rc_dev->priv;
unsigned int base_clk = clk_get_rate(ir->clk);
-   unsigned long flags;
 
unsigned int ithr = sunxi_usec_to_ithr(base_clk, timeout);
 
dev_dbg(rc_dev->dev.parent, "setting idle threshold to %u\n", ithr);
 
-   spin_lock_irqsave(>ir_lock, flags);
/* Set noise threshold and idle threshold */
writel(REG_CIR_NTHR(SUNXI_IR_RXNOISE) | REG_CIR_ITHR(ithr),
   ir->base + SUNXI_IR_CIR_REG);
-   spin_unlock_irqrestore(>ir_lock, flags);
 
rc_dev->timeout = sunxi_ithr_to_usec(base_clk, ithr);
 
@@ -199,8 +191,6 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   spin_lock_init(>ir_lock);
-
ir->fifo_size = quirks->fifo_size;
 
/* Clock */
-- 
2.26.2

-- 
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/20210113045132.31430-3-samuel%40sholland.org.

[linux-sunxi] [PATCH 1/4] media: sunxi-cir: Clean up dead register writes

[Samuel Holland]

The register writes during driver removal occur after the device is
already put back in reset, so they never had any effect.

Signed-off-by: Samuel Holland 
---
 drivers/media/rc/sunxi-cir.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 8555c7798706..0a7f7eab3cc3 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -342,22 +342,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
 
 static int sunxi_ir_remove(struct platform_device *pdev)
 {
-   unsigned long flags;
struct sunxi_ir *ir = platform_get_drvdata(pdev);
 
clk_disable_unprepare(ir->clk);
clk_disable_unprepare(ir->apb_clk);
reset_control_assert(ir->rst);
 
-   spin_lock_irqsave(>ir_lock, flags);
-   /* disable IR IRQ */
-   writel(0, ir->base + SUNXI_IR_RXINT_REG);
-   /* clear All Rx Interrupt Status */
-   writel(REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
-   /* disable IR */
-   writel(0, ir->base + SUNXI_IR_CTL_REG);
-   spin_unlock_irqrestore(>ir_lock, flags);
-
rc_unregister_device(ir->rc);
return 0;
 }
-- 
2.26.2

-- 
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/20210113045132.31430-2-samuel%40sholland.org.

[linux-sunxi] [PATCH 0/4] media: sunxi-cir: Cleanup and power management

[Samuel Holland]

This series cleans up some dead code in the sunxi-cir driver and adds
system power management hooks.

Samuel Holland (4):
  media: sunxi-cir: Clean up dead register writes
  media: sunxi-cir: Remove unnecessary spinlock
  media: sunxi-cir: Factor out hardware initialization
  media: sunxi-cir: Implement suspend/resume/shutdown callbacks

 drivers/media/rc/sunxi-cir.c | 167 ---
 1 file changed, 94 insertions(+), 73 deletions(-)

-- 
2.26.2

-- 
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/20210113045132.31430-1-samuel%40sholland.org.

[linux-sunxi] [PATCH 3/4] media: sunxi-cir: Factor out hardware initialization

[Samuel Holland]

In preparation for adding suspend/resume hooks, factor out the hardware
initialization from the driver probe/remove functions.

The timeout programmed during init is taken from the `struct rc_dev` so
it is maintained across an exit/init cycle.

This resolves some trivial issues with the probe function: throwing away
the error from clk_prepare_enable and using the wrong type for the
temporary register value.

Signed-off-by: Samuel Holland 
---
 drivers/media/rc/sunxi-cir.c | 128 ---
 1 file changed, 74 insertions(+), 54 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 48be400421cd..ccb9d6b4225d 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -169,10 +169,74 @@ static int sunxi_ir_set_timeout(struct rc_dev *rc_dev, 
unsigned int timeout)
return 0;
 }
 
+static int sunxi_ir_hw_init(struct device *dev)
+{
+   struct sunxi_ir *ir = dev_get_drvdata(dev);
+   u32 tmp;
+   int ret;
+
+   ret = reset_control_deassert(ir->rst);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(ir->apb_clk);
+   if (ret) {
+   dev_err(dev, "failed to enable apb clk\n");
+   goto exit_assert_reset;
+   }
+
+   ret = clk_prepare_enable(ir->clk);
+   if (ret) {
+   dev_err(dev, "failed to enable ir clk\n");
+   goto exit_disable_apb_clk;
+   }
+
+   /* Enable CIR Mode */
+   writel(REG_CTL_MD, ir->base + SUNXI_IR_CTL_REG);
+
+   /* Set noise threshold and idle threshold */
+   sunxi_ir_set_timeout(ir->rc, ir->rc->timeout);
+
+   /* Invert Input Signal */
+   writel(REG_RXCTL_RPPI, ir->base + SUNXI_IR_RXCTL_REG);
+
+   /* Clear All Rx Interrupt Status */
+   writel(REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
+
+   /*
+* Enable IRQ on overflow, packet end, FIFO available with trigger
+* level
+*/
+   writel(REG_RXINT_ROI_EN | REG_RXINT_RPEI_EN |
+  REG_RXINT_RAI_EN | REG_RXINT_RAL(ir->fifo_size / 2 - 1),
+  ir->base + SUNXI_IR_RXINT_REG);
+
+   /* Enable IR Module */
+   tmp = readl(ir->base + SUNXI_IR_CTL_REG);
+   writel(tmp | REG_CTL_GEN | REG_CTL_RXEN, ir->base + SUNXI_IR_CTL_REG);
+
+   return 0;
+
+exit_disable_apb_clk:
+   clk_disable_unprepare(ir->apb_clk);
+exit_assert_reset:
+   reset_control_assert(ir->rst);
+
+   return ret;
+}
+
+static void sunxi_ir_hw_exit(struct device *dev)
+{
+   struct sunxi_ir *ir = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(ir->clk);
+   clk_disable_unprepare(ir->apb_clk);
+   reset_control_assert(ir->rst);
+}
+
 static int sunxi_ir_probe(struct platform_device *pdev)
 {
int ret = 0;
-   unsigned long tmp = 0;
 
struct device *dev = >dev;
struct device_node *dn = dev->of_node;
@@ -213,43 +277,26 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rst = devm_reset_control_get_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
return PTR_ERR(ir->rst);
-   ret = reset_control_deassert(ir->rst);
-   if (ret)
-   return ret;
}
 
ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
-   goto exit_reset_assert;
+   return ret;
}
dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
 
-   if (clk_prepare_enable(ir->apb_clk)) {
-   dev_err(dev, "try to enable apb_ir_clk failed\n");
-   ret = -EINVAL;
-   goto exit_reset_assert;
-   }
-
-   if (clk_prepare_enable(ir->clk)) {
-   dev_err(dev, "try to enable ir_clk failed\n");
-   ret = -EINVAL;
-   goto exit_clkdisable_apb_clk;
-   }
-
/* IO */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ir->base = devm_ioremap_resource(dev, res);
if (IS_ERR(ir->base)) {
-   ret = PTR_ERR(ir->base);
-   goto exit_clkdisable_clk;
+   return PTR_ERR(ir->base);
}
 
ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir->rc) {
dev_err(dev, "failed to allocate device\n");
-   ret = -ENOMEM;
-   goto exit_clkdisable_clk;
+   return -ENOMEM;
}
 
ir->rc->priv = ir;
@@ -265,6 +312,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
/* Frequency after IR internal divider with sample period in us */
ir->rc->rx_resolution = (USEC_PE

[linux-sunxi] [PATCH v2 1/3] dt-bindings: sun4i-a10-lradc-keys: Accept wakeup-source property

[Samuel Holland]

The LRADC provides an interrupt that can be used to wake the system.
Signify this by accepting a "wakeup-source" property in the binding.

Signed-off-by: Samuel Holland 
---
 .../bindings/input/allwinner,sun4i-a10-lradc-keys.yaml  | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml 
b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
index cffd02028d02..d74f2002409e 100644
--- 
a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
+++ 
b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
@@ -29,6 +29,8 @@ properties:
 description:
   Regulator for the LRADC reference voltage
 
+  wakeup-source: true
+
 patternProperties:
   "^button-[0-9]+$":
 type: object
-- 
2.26.2

-- 
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/20210113040542.34247-2-samuel%40sholland.org.

[linux-sunxi] [PATCH v2 2/3] input: sun4i-lradc-keys - Add wakup support

[Samuel Holland]

From: Ondrej Jirman 

Allow the driver to wake the system on key press if the "wakeup-source"
property is provided in the device tree. Using the LRADC as a wakeup
source requires keeping the AVCC domain active during sleep. Since this
has a nontrivial impact on power consumption (sometimes doubling it),
disable the LRADC wakeup source by default.

Signed-off-by: Ondrej Jirman 
Signed-off-by: Samuel Holland 
---
 drivers/input/keyboard/sun4i-lradc-keys.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c 
b/drivers/input/keyboard/sun4i-lradc-keys.c
index 4a796bed48ac..a1eb2001c088 100644
--- a/drivers/input/keyboard/sun4i-lradc-keys.c
+++ b/drivers/input/keyboard/sun4i-lradc-keys.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -226,8 +228,7 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
 {
struct sun4i_lradc_data *lradc;
struct device *dev = >dev;
-   int i;
-   int error;
+   int error, i, irq;
 
lradc = devm_kzalloc(dev, sizeof(struct sun4i_lradc_data), GFP_KERNEL);
if (!lradc)
@@ -272,8 +273,13 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
if (IS_ERR(lradc->base))
return PTR_ERR(lradc->base);
 
-   error = devm_request_irq(dev, platform_get_irq(pdev, 0),
-sun4i_lradc_irq, 0,
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   dev_err(>dev, "Failed to get IRQ\n");
+   return irq;
+   }
+
+   error = devm_request_irq(dev, irq, sun4i_lradc_irq, 0,
 "sun4i-a10-lradc-keys", lradc);
if (error)
return error;
@@ -282,6 +288,14 @@ static int sun4i_lradc_probe(struct platform_device *pdev)
if (error)
return error;
 
+   if (device_property_read_bool(dev, "wakeup-source")) {
+   device_set_wakeup_capable(dev, true);
+
+   error = dev_pm_set_wake_irq(dev, irq);
+   if (error)
+   dev_warn(dev, "Failed to set wake IRQ\n");
+   }
+
return 0;
 }
 
-- 
2.26.2

-- 
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/20210113040542.34247-3-samuel%40sholland.org.

[linux-sunxi] [PATCH v2 0/3] PinePhone volume key (LRADC) wakeup support

[Samuel Holland]

This series allows the volume keys on the PinePhone to wake up the
device. As pointed out for v1, wakeup should only be enabled when a
"wakeup-source" property is present, so v2 requires DT and binding
changes in addition to the driver change.

Changes since v1:
  - Add requisite DT binding change
  - Only add wakeup capability if "wakeup-source" is present
  - Warn but do not error out if setting the wake IRQ fails
  - Add "wakeup-source" property to PinePhone device tree

Ondrej Jirman (1):
  input: sun4i-lradc-keys -  Add wakup support

Samuel Holland (2):
  dt-bindings: sun4i-a10-lradc-keys: Accept wakeup-source property
  arm64: dts: allwinner: pinephone: Support volume key wakeup

 .../input/allwinner,sun4i-a10-lradc-keys.yaml |  2 ++
 .../dts/allwinner/sun50i-a64-pinephone.dtsi   |  1 +
 drivers/input/keyboard/sun4i-lradc-keys.c | 22 +++
 3 files changed, 21 insertions(+), 4 deletions(-)

-- 
2.26.2

-- 
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/20210113040542.34247-1-samuel%40sholland.org.

[linux-sunxi] [PATCH v2 3/3] arm64: dts: allwinner: pinephone: Support volume key wakeup

[Samuel Holland]

PinePhone volume keys are connected to the LRADC in the A64. Users may
want to use them to wake the device from sleep. Support this by
declaring the LRADC as a wakeup source.

Signed-off-by: Samuel Holland 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
index 2dfe9bae8c67..7f37f9fea0ab 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
@@ -196,6 +196,7 @@  {
 
  {
vref-supply = <_aldo3>;
+   wakeup-source;
status = "okay";
 
button-200 {
-- 
2.26.2

-- 
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/20210113040542.34247-4-samuel%40sholland.org.

Re: [linux-sunxi] [PATCH v2 07/21] sunxi: support loading with SPL > 32KB

[Samuel Holland]

On 1/11/21 2:11 PM, Jernej Skrabec wrote:
> From: Andre Przywara 
> 
> H616 supports and needs bigger SPL than 32 KiB, mostly due to big DRAM
> driver and need for PMIC configuration, which pulls several drivers which
> are not needed otherwise.
> 
> spl_mmc_get_uboot_raw_sector() will now compare pre-configured size with
> that, reported in SPL header. If size in header is bigger, it will use
> that value instead.
> 
> In the process of function rework, also add missing function argument.

Reviewed-by: Samuel Holland 

Cheers,
Samuel

-- 
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/3dede399-0487-deb5-8645-35e296256f78%40sholland.org.

Re: [linux-sunxi] [PATCH v2 05/21] sunxi: prcm: Add memory map for H6 like SoCs

[Samuel Holland]

On 1/11/21 2:11 PM, Jernej Skrabec wrote:
> There was no need to have prcm definitions for H6 and similar SoCs till
> now. However, support R_I2C will be needed soon in SPL.
> 
> Move old definitions to prcm_sun6i.h and add new ones in prcm_sun50i.h.
> One of those files will be selected in common prcm.h based on defined
> macros.
> 
> This commit doesn't do any functional change.
> 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Samuel Holland 

Cheers,
Samuel

-- 
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/07d7b36b-6062-96ff-ef1b-64174ab9ae3e%40sholland.org.

Re: [linux-sunxi] [PATCH v2 02/21] sunxi: Introduce common symbol for H6 like SoCs

[Samuel Holland]

On 1/11/21 2:11 PM, Jernej Skrabec wrote:
> It turns out that there are at least 2 other SoCs which have basically
> the same memory map, similar clocks and other features as H6. It's very
> likely that we'll see more such SoCs in the future. In order to ease
> porting to new SoCs and lower ifdef clutter, introduce common symbol for
> them.
> 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Samuel Holland 

Cheers,
Samuel

-- 
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/9cf9b64d-63ce-3e5e-b703-2e8cc1403bcc%40sholland.org.

Re: [linux-sunxi] [PATCH v6 3/3] arm64: dts: sun50i: Add support for Orange Pi 3

[Samuel Holland]

On 1/10/21 1:29 PM, Jernej Skrabec wrote:
> From: Andre Heider 
> 
> dts file is taken from Linux 5.11-rc1 tag.
> 
> The Bluetooth controller of this device ships with a default address,
> use the new CONFIG_FIXUP_BDADDR option to fix it up.

This still references the old config name. It should be
CONFIG_BLUETOOTH_DT_DEVICE_FIXUP.

Cheers,
Samuel

> akonadi:?collection=30=INBOX
> Acked-by: Maxime Ripard 
> Signed-off-by: Andre Heider 
> [Updated OrangePi 3 DT, rebase and config update]
> Signed-off-by: Jernej Skrabec 

-- 
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/fdc90774-3390-ef11-de84-2cef4066809b%40sholland.org.

[linux-sunxi] Re: [PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

[Samuel Holland]

On 12/31/20 8:29 AM, Paul Kocialkowski wrote:
> The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
> found on Allwinner SoCs such as the A31 and V3/V3s.
> 
> It is a standalone block, connected to the CSI controller on one side
> and to the MIPI D-PHY block on the other. It has a dedicated address
> space, interrupt line and clock.
> 
> It is represented as a V4L2 subdev to the CSI controller and takes a
> MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
> media controller API.
> 
> Only 8-bit and 10-bit Bayer formats are currently supported.
> While up to 4 internal channels to the CSI controller exist, only one
> is currently supported by this implementation.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/media/platform/sunxi/Kconfig  |   1 +
>  drivers/media/platform/sunxi/Makefile |   1 +
>  .../platform/sunxi/sun6i-mipi-csi2/Kconfig|  12 +
>  .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
>  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 590 ++
>  .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 117 
>  6 files changed, 725 insertions(+)
>  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
>  create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
>  create mode 100644 
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
>  create mode 100644 
> drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h
> 
> diff --git a/drivers/media/platform/sunxi/Kconfig 
> b/drivers/media/platform/sunxi/Kconfig
> index 7151cc249afa..9684e07454ad 100644
> --- a/drivers/media/platform/sunxi/Kconfig
> +++ b/drivers/media/platform/sunxi/Kconfig
> @@ -2,3 +2,4 @@
>  
>  source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
>  source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
> +source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
> diff --git a/drivers/media/platform/sunxi/Makefile 
> b/drivers/media/platform/sunxi/Makefile
> index fc537c9f5ca9..887a7cae8fca 100644
> --- a/drivers/media/platform/sunxi/Makefile
> +++ b/drivers/media/platform/sunxi/Makefile
> @@ -2,5 +2,6 @@
>  
>  obj-y+= sun4i-csi/
>  obj-y+= sun6i-csi/
> +obj-y+= sun6i-mipi-csi2/
>  obj-y+= sun8i-di/
>  obj-y+= sun8i-rotate/
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig 
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> new file mode 100644
> index ..47f1bb0779a8
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
> @@ -0,0 +1,12 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config VIDEO_SUN6I_MIPI_CSI2
> + tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + depends on PM && COMMON_CLK && VIDEO_V4L2
> + select REGMAP_MMIO
> + select PHY_SUN6I_MIPI_DPHY
> + select MEDIA_CONTROLLER
> + select VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> + help
> +Support for the Allwinner A31 MIPI CSI-2 Controller.
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile 
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> new file mode 100644
> index ..14e4e03818b5
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
> +
> +obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
> diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c 
> b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> new file mode 100644
> index ..87307beda4cf
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
> @@ -0,0 +1,590 @@
[...]
> +/* Base Driver */
> +
> +static int sun6i_mipi_csi2_suspend(struct device *dev)
> +{
> + struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(cdev->clk_mod);
> + clk_disable_unprepare(cdev->clk_bus);
> + reset_control_assert(cdev->reset);
> +
> + return 0;
> +}
> +
> +static int sun6i_mipi_csi2_resume(struct device *dev)
> +{
> + struct sun6i_mipi_csi2_dev *cdev = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = reset_control_deassert(cdev->reset);
> + if (ret) {
> + dev_err(cdev->dev, "failed to deassert reset\n");
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(cdev->clk_bus);
> + if (ret) {
> + dev_err(cdev->dev, "failed to enable bus clock\n");
> + goto error_reset;
> + }
> +
> + ret = clk_prepare_enable(cdev->clk_mod);
> + if (ret) {
> + dev_err(cdev->dev, "failed to enable module clock\n");
> + goto error_clk_bus;
> + }
> +
> + return 0;
> +
> +error_clk_bus:
> + clk_disable_unprepare(cdev->clk_bus);
> +
> +error_reset:
> + 

[linux-sunxi] Re: [PATCH v3 01/10] dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi

[Samuel Holland]

On 1/8/21 3:44 AM, Maxime Ripard wrote:
> Hi Samuel,
> 
> Thanks a lot for working on this
> 
> I'm fine with the rest of the work, but I have a couple of questions
> 
> On Sun, Jan 03, 2021 at 04:30:52AM -0600, Samuel Holland wrote:
>> The R_INTC in the A31 and newer sun8i/sun50i SoCs has additional
>> functionality compared to the sun7i/sun9i NMI controller. Among other
>> things, it multiplexes up to 128 interrupts corresponding to (and in
>> parallel to) the first 128 GIC SPIs. This means the NMI is no longer the
>> lowest-numbered interrupt, since it is SPI 32 or 96 (depending on SoC).
>>
>> To allow access to all multiplexed IRQs, the R_INTC requires a new
>> binding where the interrupt number matches the GIC interrupt number.
>> For simplicity, copy the three-cell GIC binding; this disambiguates
>> interrupt 0 in the old binding (the NMI) from interrupt 0 in the new
>> binding (SPI 0) by the number of cells.
> 
> It's not really clear to me what the ambiguity is between the NMI and
> the SPI 0 interrupt?

Here's the ASCII art I will include in v4:

NMI IRQ   DIRECT IRQs  MUXED IRQs
 bit 0 bits 1-18   bits 19-31

  +-+ +-+   +-+  +-+
  | NMI Pad | |  IRQ d  |   |  IRQ m  |  | IRQ m+7 |
  +-+ +-+   +-+  +-+
   || |||  ||
   || |||..||
+--V--+ +-+ | || +--V--V--+ |
|   Invert/   | |Write| | || |  AND with  | |
| Edge Detect | |  PENDING[0] | | || |  MUX[m/8]  | |
+-+ +-+ | || ++ |
   |   || ||   ||
+--V---V--+  +--V--+  | +--V--+| +--V--+
| SetReset|  | GIC |  | | GIC || | GIC |
|Latch|  | SPI |  | | SPI |... |  ...| SPI |
+-+  | N+d |  | |  m  || | m+7 |
| |  +-+  | +-+| +-+
| |   ||
+---V-+ +-V---+ +-V---+  +-V--+
| GIC SPI | |   AND with  | |   AND with  |  |  AND with  |
| N (=32) | |  ENABLE[0]  | |  ENABLE[d]  |  |   ENABLE[19+m/8]   |
+-+ +-+ +-+  ++
   |   |   |
+--V--+ +--V--+  +-V--+
|Read | |Read |  |   Read |
|  PENDING[0] | |  PENDING[d] |  |   PENDING[19+m/8]  |
+-+ +-+  ++

There are two overlapping ranges of IRQs supported by the controller,
and so there are two different IRQs you could call "IRQ 0":
  - Bit 0 of PENDING/ENABLE/MASK, aka d==0, the NMI
- This maps to bit 32 of the MUX register range (SPI 32)
- This is what the old binding calls "IRQ 0"
  - Bit 0 of MUX, aka m==0, aka SPI 0, the UART0 IRQ
- This maps to bit 19 of PENDING/ENABLE/MASK
- This is what the new binding calls "IRQ 0"

You can see this insertion in the middle of the MUX range when looking
at the mask of implemented MUX bits in the A31 variant:
  0x,
  0xfff8, <<< this gap here is for the 19 direct IRQs
  0x,
  0x000f,

If you call the NMI "IRQ 0", then there is no way to specify the muxed
IRQs. SPI 0 maps to bit 19, but so do SPI 1-7. So if I was to specify
"IRQ 19", you wouldn't know which of those 8 muxed SPIs I am referring to.

On the other hand, if you call the first muxed IRQ "IRQ 0", then there
is an unambiguous number for every interrupt supported by this driver.

> In general, it looks like switching to a 3-cell binding with the GIC SPI
> value looks weird to me, since the GIC isn't the parent at all of these
> interrupts.

The GIC is *a* parent of all of these interrupts, and is *the* parent of
the NMI.

> If the ambiguity is that a stacked irqchip driver needs to have the same
> interrupt number than the GIC, and that the 0 interrupt for the NMI
> controller (used by the PMIC) and is actually the 32 (or 96) GIC
> interrupt and thus breaks that requirement, can't we fix this in the
> driver based on the compatible?

No, while the NMI is direct "IRQ 0" at this irqchip, it is *also* muxed
"IRQ 32" at this same irqchip.

> Something like if the interrupt number is 0, with a A31 or newer
> compatible, then add the p

[linux-sunxi] Re: [PATCH v4 0/3] tools/sunxi: Use mkimage for SPL generation

[Samuel Holland]

On 1/6/21 3:24 AM, Andre Przywara wrote:
> Hi,
> 
> a small update fixing the strncpy bug and addressing too long DT names
> properly. Thanks to Samuel for pointing this out.
> ==
> 
> So far creating a bootable SPL image for Allwinner based boards uses
> the mksunxiboot tool. Most other platforms seemed to have integrated this
> kind of functionality into the common mkimage tool.
> 
> Since there is nothing special about the Allwinner image in this respect,
> just add support for the so-called "eGON" image type into mkimage. If there
> was a particular reason this hasn't been done before, please let me know.
> 
> This will eventually allow us to remove mksunxiboot, but I leave it around
> for now in case of regressions and since some people depend on it from
> external projects.
> 
> Patch 1/3 splits some existing sunxi specific header file, so we can
> share the eGON header definition between the tools and the SPL.
> Patch 2/3 adds the actual support to mkimage, patch 3/3 then switches
> the Makefile to use mkimage instead of mksunxiboot.
> 
> I tested all 152 Allwinner boards by building each
> u-boot-sunxi-with-spl.bin and comparing them against the version created
> using mksunxiboot (using SOURCE_DATE_EPOCH and .scmversion to create
> reproducible builds, and by reverting just patch 3/3).
> All files before and after were identical.
> 
> Cheers,
> Andre
> 
> Changelog v3 .. v4:
> - properly check DT name length before inserting into header
> 
> Changelog v2 .. v3:
> - factor out eGON struct into separate header file
> - only print extended header information when applicable
> - remove redundant alignment
> - minor cosmetic fixes
> 
> Changelog v1 .. v2:
> - Drop already merged cleanup patch (v1 1/3)
> - replace relative include path
> - remove already defined ALIGN macro
> - rebase against current master
> 
> Andre Przywara (3):
>   sunxi: Factor out eGON BROM header description
>   tools: mkimage: Add Allwinner eGON support
>   sunxi: Use mkimage for SPL boot image generation
> 
>  arch/arm/include/asm/arch-sunxi/spl.h |  65 +---
>  common/image.c|   1 +
>  include/image.h   |   1 +
>  include/sunxi_image.h |  82 
>  scripts/Makefile.spl  |   8 +-
>  tools/Makefile|   1 +
>  tools/sunxi_egon.c| 136 ++++++++++
>  7 files changed, 226 insertions(+), 68 deletions(-)
>  create mode 100644 include/sunxi_image.h
>  create mode 100644 tools/sunxi_egon.c

For the series:

Reviewed-by: Samuel Holland 
Tested-by: Samuel Holland 

-- 
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/1a973ff4-f520-592e-26e5-87be5b21b937%40sholland.org.

[linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Samuel Holland]

On 1/6/21 5:38 AM, Chen-Yu Tsai wrote:
> On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard  wrote:
>>
>> On Mon, Jan 04, 2021 at 10:54:19AM +, André Przywara wrote:
>>> On 03/01/2021 10:00, Samuel Holland wrote:
>>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers
>>>> PMIC, configure the connection to use the RSB bus rather than the I2C
>>>> bus. Compared to the I2C controller that shares the pins, the RSB
>>>> controller allows a higher bus frequency, and it is more CPU-efficient.
>>>
>>> But is it really necessary to change the DTs for those boards in this
>>> way? It means those newer DTs now become incompatible with older
>>> kernels, and I don't know if those reasons above really justify this.
>>>
>>> I understand that we officially don't care about "newer DTs on older
>>> kernels", but do we really need to break this deliberately, for no
>>> pressing reasons?
>>>
>>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs,
>>> just want to avoid breaking existing ones.
>>
>> Doing so would also introduce some inconsistencies, one more thing to
>> consider during reviews, and would require more testing effort.
>>
>> I'm not sure that stretching our - already fairly sparse - resources
>> thin would be very wise here, especially for something that we don't
>> have to do and for a setup that isn't really used that much.
> 
> As soon as some software component starts running RSB, (which I assume
> is what Samuel is planning to do in Crust?), there's a chance that it
> doesn't switch the chip back to I2C. And then Linux won't be able to
> access it.

Crust can handle either way via a config option, which currently
defaults to I2C for H6. It must use the same selection as Linux, not
only because of the PMIC mode, but also because of the pinctrl.

TF-A is already converted to use RSB[1], and it does switch the PMIC
back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is
fine. However, Linux currently does not switch the PMIC back. So the
most likely problem from this patch is that, with new Linux + old TF-A,
TF-A will be unable to power down the board or access regulators after
an SoC reset.

I expect there will be a TF-A release between now and when 5.12 hits
stable, but people tend not upgrade their U-Boot/TF-A very often.

We could solve this by having the Linux RSB driver switch all child
devices back to I2C in .shutdown, or by dropping this patch and only
using RSB for new boards (which would also address Andre's concern).

Cheers,
Samuel

[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576
[2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575

> So I'm for keeping things consistent and converting all users to RSB.
> 
> 
> ChenYu
> 

-- 
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/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.

[linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Samuel Holland]

On 1/4/21 4:54 AM, André Przywara wrote:
> On 03/01/2021 10:00, Samuel Holland wrote:
>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers
>> PMIC, configure the connection to use the RSB bus rather than the I2C
>> bus. Compared to the I2C controller that shares the pins, the RSB
>> controller allows a higher bus frequency, and it is more CPU-efficient.
> 
> But is it really necessary to change the DTs for those boards in this
> way? It means those newer DTs now become incompatible with older
> kernels, and I don't know if those reasons above really justify this.
> 
> I understand that we officially don't care about "newer DTs on older
> kernels", but do we really need to break this deliberately, for no
> pressing reasons?

That's a reasonable concern. I am fine if you want to delay or drop patch 4.

Cheers,
Samuel

> Cheers,
> Andre
> 
> P.S. I am fine with supporting RSB on H6, and even using it on new DTs,
> just want to avoid breaking existing ones.
> 
>> Signed-off-by: Samuel Holland 
>> ---
>>  .../dts/allwinner/sun50i-h6-beelink-gs1.dts   | 38 +--
>>  .../dts/allwinner/sun50i-h6-orangepi-3.dts| 14 +++
>>  .../dts/allwinner/sun50i-h6-orangepi.dtsi | 22 +--
>>  3 files changed, 37 insertions(+), 37 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts 
>> b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
>> index 7c9dbde645b5..3452add30cc4 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
>> @@ -150,12 +150,28 @@  {
>>  vcc-pg-supply = <_aldo1>;
>>  };
>>  
>> -_i2c {
>> +_ir {
>> +linux,rc-map-name = "rc-beelink-gs1";
>> +status = "okay";
>> +};
>> +
>> +_pio {
>> +/*
>> + * FIXME: We can't add that supply for now since it would
>> + * create a circular dependency between pinctrl, the regulator
>> + * and the RSB Bus.
>> + *
>> + * vcc-pl-supply = <_aldo1>;
>> + */
>> +vcc-pm-supply = <_aldo1>;
>> +};
>> +
>> +_rsb {
>>  status = "okay";
>>  
>> -axp805: pmic@36 {
>> +axp805: pmic@745 {
>>  compatible = "x-powers,axp805", "x-powers,axp806";
>> -reg = <0x36>;
>> +reg = <0x745>;
>>  interrupt-parent = <_intc>;
>>  interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>  interrupt-controller;
>> @@ -273,22 +289,6 @@ sw {
>>  };
>>  };
>>  
>> -_ir {
>> -linux,rc-map-name = "rc-beelink-gs1";
>> -status = "okay";
>> -};
>> -
>> -_pio {
>> -/*
>> - * PL0 and PL1 are used for PMIC I2C
>> - * don't enable the pl-supply else
>> - * it will fail at boot
>> - *
>> - * vcc-pl-supply = <_aldo1>;
>> - */
>> -vcc-pm-supply = <_aldo1>;
>> -};
>> -
>>   {
>>  clocks = <_osc32k>;
>>  };
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts 
>> b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
>> index 15c9dd8c4479..16702293ac0b 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
>> @@ -175,12 +175,16 @@  {
>>  vcc-pg-supply = <_vcc_wifi_io>;
>>  };
>>  
>> -_i2c {
>> +_ir {
>> +status = "okay";
>> +};
>> +
>> +_rsb {
>>  status = "okay";
>>  
>> -axp805: pmic@36 {
>> +axp805: pmic@745 {
>>  compatible = "x-powers,axp805", "x-powers,axp806";
>> -reg = <0x36>;
>> +reg = <0x745>;
>>  interrupt-parent = <_intc>;
>>  interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>  interrupt-controller;
>> @@ -291,10 +295,6 @@ sw {
>>  };
>>  };
>>  
>> -_ir {
>> -status = "okay";
>> -};
>> -
>>   {
>>  clocks = <_osc32k>;
>>  };
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi 
>> b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
>> index ebc120a9232f..23e3cb2ffd8d 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
>> +++ b/a

Re: [linux-sunxi] [PATCH 11/17] sunxi: Add H616 DRAM support

[Samuel Holland]

On 1/4/21 12:39 PM, Jernej Škrabec wrote:
> Dne ponedeljek, 04. januar 2021 ob 03:39:52 CET je Samuel Holland napisal(a):
>> On 1/3/21 3:26 AM, Jernej Skrabec wrote:
>>> Allwinner H616 supports many types of DRAM. Most notably it supports
>>> LPDDR4. However, all commercially available boards at this time use
>>> only DDR3, so this commit adds only DDR3 support.
>>>
>>> Controller and MBUS are very similar to H6 but PHY is completely
>>> unknown.
>>>
>>> Signed-off-by: Jernej Skrabec 
>>> ---
>>>
>>>  arch/arm/include/asm/arch-sunxi/dram.h|2 +
>>>  .../include/asm/arch-sunxi/dram_sun50i_h616.h |  159 +++
>>>  arch/arm/mach-sunxi/Kconfig   |   43 +
>>>  arch/arm/mach-sunxi/Makefile  |2 +
>>>  arch/arm/mach-sunxi/dram_sun50i_h616.c| 1023 +
>>>  arch/arm/mach-sunxi/dram_timings/Makefile |2 +
>>>  .../mach-sunxi/dram_timings/h616_ddr3_1333.c  |   94 ++
>>>  7 files changed, 1325 insertions(+)
>>>  create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
>>>  create mode 100644 arch/arm/mach-sunxi/dram_sun50i_h616.c
>>>  create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_ddr3_1333.c
>>>
>>> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
>>> b/arch/arm/include/asm/arch-sunxi/dram.h index 8002b7efdc19..c3b3e1f512b2
>>> 100644
>>> --- a/arch/arm/include/asm/arch-sunxi/dram.h
>>> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
>>> @@ -29,6 +29,8 @@
>>>
>>>  #include 
>>>  #elif defined(CONFIG_MACH_SUN50I_H6)
>>>  #include 
>>>
>>> +#elif defined(CONFIG_MACH_SUN50I_H616)
>>> +#include 
>>>
>>>  #else
>>>  #include 
>>>  #endif
>>>
>>> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
>>> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h new file mode 100644
>>> index ..5d105afd6110
>>> --- /dev/null
>>> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
>>> @@ -0,0 +1,159 @@
>>> +/*
>>> + * H616 dram controller register and constant defines
>>> + *
>>> + * (C) Copyright 2020  Jernej Skrabec 
>>> + *
>>> + * Based on H6 one, which is:
>>> + * (C) Copyright 2017  Icenowy Zheng 
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#ifndef _SUNXI_DRAM_SUN50I_H616_H
>>> +#define _SUNXI_DRAM_SUN50I_H616_H
>>> +
>>> +#include 
>>> +#ifndef __ASSEMBLY__
>>> +#include 
>>> +#endif
>>> +
>>> +enum sunxi_dram_type {
>>> +   SUNXI_DRAM_TYPE_DDR3 = 3,
>>> +   SUNXI_DRAM_TYPE_DDR4,
>>> +   SUNXI_DRAM_TYPE_LPDDR3 = 7,
>>> +   SUNXI_DRAM_TYPE_LPDDR4
>>> +};
>>> +
>>> +/* MBUS part is largely the same as in H6, except for one special
>>> register */ +struct sunxi_mctl_com_reg {
>>> +   u32 cr; /* 0x000 control register */
>>> +   u8 reserved_0x004[4];   /* 0x004 */
>>> +   u32 unk_0x008;  /* 0x008 */
>>> +   u32 tmr;/* 0x00c timer register */
>>> +   u8 reserved_0x010[4];   /* 0x010 */
>>> +   u32 unk_0x014;  /* 0x014 */
>>> +   u8 reserved_0x018[8];   /* 0x018 */
>>> +   u32 maer0;  /* 0x020 master enable register 0 */
>>> +   u32 maer1;  /* 0x024 master enable register 1 */
>>> +   u32 maer2;  /* 0x028 master enable register 2 */
>>> +   u8 reserved_0x02c[468]; /* 0x02c */
>>> +   u32 bwcr;   /* 0x200 bandwidth control register */
>>> +   u8 reserved_0x204[12];  /* 0x204 */
>>> +   /*
>>> +* The last master configured by BSP libdram is at 0x49x, so the
>>> +* size of this struct array is set to 41 (0x29) now.
>>> +*/
>>> +   struct {
>>> +   u32 cfg0;   /* 0x0 */
>>> +   u32 cfg1;   /* 0x4 */
>>> +   u8 reserved_0x8[8]; /* 0x8 */
>>> +   } master[41];   /* 0x210 + index * 0x10 */
>>> +   u8 reserved_0x4a0[96];  /* 0x4a0 */
>>> +   u32 unk_0x500;  /* 0x500 */
>>> +};
>>> +check_member(sunxi_mctl_com_reg, unk_0x500, 0x500);
>>> +
>>> +/*
>>> + * Controller registers seems to be the same or at least very similar
>>> + * to those in H6.
>>> + */
>>> +struct s

Re: [linux-sunxi] [PATCH 12/17] sunxi: Add support for H616 SoC

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> H616 is very similar to H6 so most of the infrastructure can be reused.
> However, two big differences are that it doesn't have functional SRAM A2
> which is usually used for TF-A and it doesn't have ARISC co-processor.
> It also needs bigger SPL size - 48 KiB.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/dts/sunxi-u-boot.dtsi  |  9 +
>  arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h |  7 +++
>  arch/arm/mach-sunxi/Kconfig | 11 ++-
>  arch/arm/mach-sunxi/cpu_info.c  |  2 ++
>  drivers/power/Kconfig   |  1 +
>  include/configs/sunxi-common.h  | 10 ++
>  6 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
> index c77cf7cacf0c..7e8644f390a8 100644
> --- a/arch/arm/dts/sunxi-u-boot.dtsi
> +++ b/arch/arm/dts/sunxi-u-boot.dtsi
> @@ -3,6 +3,9 @@
>  #ifdef CONFIG_MACH_SUN50I_H6
>  #define BL31_ADDR 0x104000
>  #define  SCP_ADDR 0x114000
> +#elif defined(CONFIG_MACH_SUN50I_H616)
> +#define BL31_ADDR 0x40004000
> +#define  SCP_ADDR 0x028000

There should be no SCP_ADDR if there is no SCP firmware.

>  #else
>  #define BL31_ADDR  0x44000
>  #define  SCP_ADDR  0x5
> @@ -61,6 +64,7 @@
>   };
>   };
>  
> +#ifndef CONFIG_MACH_SUN50I_H616
>   scp {
>   description = "SCP firmware";
>   type = "firmware";
> @@ -73,6 +77,7 @@
>   missing-msg = "scp-sunxi";
>   };
>   };
> +#endif
>  
>   @fdt-SEQ {
>   description = "NAME";
> @@ -87,7 +92,11 @@
>   @config-SEQ {
>   description = "NAME";
>   firmware = "atf";
> +#ifdef CONFIG_MACH_SUN50I_H616
> + loadables = "uboot";
> +#else
>   loadables = "scp", "uboot";
> +#endif
>   fdt = "fdt-SEQ";
>   };
>   };
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h 
> b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> index 6392cb07b472..d9cf8ae04288 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
> @@ -28,13 +28,20 @@
>  #define SUNXI_GIC400_BASE0x0302
>  #define SUNXI_IOMMU_BASE 0x030F
>  
> +#ifdef CONFIG_MACH_SUN50I_H6
>  #define SUNXI_DRAM_COM_BASE  0x04002000
>  #define SUNXI_DRAM_CTL0_BASE 0x04003000
>  #define SUNXI_DRAM_PHY0_BASE 0x04005000
> +#endif
>  #define SUNXI_NFC_BASE   0x04011000
>  #define SUNXI_MMC0_BASE  0x0402
>  #define SUNXI_MMC1_BASE  0x04021000
>  #define SUNXI_MMC2_BASE  0x04022000
> +#ifdef CONFIG_MACH_SUN50I_H616
> +#define SUNXI_DRAM_COM_BASE  0x047FA000
> +#define SUNXI_DRAM_CTL0_BASE 0x047FB000
> +#define SUNXI_DRAM_PHY0_BASE 0x0480
> +#endif
>  
>  #define SUNXI_UART0_BASE 0x0500
>  #define SUNXI_UART1_BASE 0x05000400
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 1a5497989f04..859b30d74ceb 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -190,9 +190,10 @@ config MACH_SUNXI_H3_H5
>   select SUPPORT_SPL
>  
>  # TODO: try out A80's 8GiB DRAM space
> +# TODO: H616 supports 4 GiB DRAM space
>  config SUNXI_DRAM_MAX_SIZE
>   hex
> - default 0xC000 if MACH_SUN50I || MACH_SUN50I_H5 || MACH_SUN50I_H6
> + default 0xC000 if MACH_SUN50I || MACH_SUN50I_H5 || MACH_SUN50I_H6 
> || MACH_SUN50I_H616
>   default 0x8000
>  
>  choice
> @@ -354,6 +355,12 @@ config MACH_SUN50I_H6
>   select PHY_SUN4I_USB
>   select DRAM_SUN50I_H6
>  
> +config MACH_SUN50I_H616
> + bool "sun50i (Allwinner H616)"
> + select ARM64
> + select DRAM_SUN50I_H616
> + select SUN50I_GEN_H6
> +
>  endchoice
>  
>  # The sun8i SoCs share a lot, this helps to avoid a lot of "if A23 || A33"
> @@ -589,6 +596,7 @@ config SYS_CLK_FREQ
>   default 81600 if MACH_SUN50I || MACH_SUN50I_H5
>   default 100800 if MACH_SUN8I
>   default 100800 if MACH_SUN9I
> + default 100800 if MACH_SUN50I_H616
>  
>  config SYS_CONFIG_NAME
>   default "sun4i" if MACH_SUN4I
> @@ -599,6 +607,7 @@ config SYS_CONFIG_NAME
>   default "sun9i" if MACH_SUN9I
>   default "sun50i" if MACH_SUN50I
>   default "sun50i" if MACH_SUN50I_H6
> + default "sun50i" if 

Re: [linux-sunxi] [PATCH 11/17] sunxi: Add H616 DRAM support

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> Allwinner H616 supports many types of DRAM. Most notably it supports
> LPDDR4. However, all commercially available boards at this time use
> only DDR3, so this commit adds only DDR3 support.
> 
> Controller and MBUS are very similar to H6 but PHY is completely
> unknown.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/include/asm/arch-sunxi/dram.h|2 +
>  .../include/asm/arch-sunxi/dram_sun50i_h616.h |  159 +++
>  arch/arm/mach-sunxi/Kconfig   |   43 +
>  arch/arm/mach-sunxi/Makefile  |2 +
>  arch/arm/mach-sunxi/dram_sun50i_h616.c| 1023 +
>  arch/arm/mach-sunxi/dram_timings/Makefile |2 +
>  .../mach-sunxi/dram_timings/h616_ddr3_1333.c  |   94 ++
>  7 files changed, 1325 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
>  create mode 100644 arch/arm/mach-sunxi/dram_sun50i_h616.c
>  create mode 100644 arch/arm/mach-sunxi/dram_timings/h616_ddr3_1333.c
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h 
> b/arch/arm/include/asm/arch-sunxi/dram.h
> index 8002b7efdc19..c3b3e1f512b2 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> @@ -29,6 +29,8 @@
>  #include 
>  #elif defined(CONFIG_MACH_SUN50I_H6)
>  #include 
> +#elif defined(CONFIG_MACH_SUN50I_H616)
> +#include 
>  #else
>  #include 
>  #endif
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> new file mode 100644
> index ..5d105afd6110
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h616.h
> @@ -0,0 +1,159 @@
> +/*
> + * H616 dram controller register and constant defines
> + *
> + * (C) Copyright 2020  Jernej Skrabec 
> + *
> + * Based on H6 one, which is:
> + * (C) Copyright 2017  Icenowy Zheng 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#ifndef _SUNXI_DRAM_SUN50I_H616_H
> +#define _SUNXI_DRAM_SUN50I_H616_H
> +
> +#include 
> +#ifndef __ASSEMBLY__
> +#include 
> +#endif
> +
> +enum sunxi_dram_type {
> + SUNXI_DRAM_TYPE_DDR3 = 3,
> + SUNXI_DRAM_TYPE_DDR4,
> + SUNXI_DRAM_TYPE_LPDDR3 = 7,
> + SUNXI_DRAM_TYPE_LPDDR4
> +};
> +
> +/* MBUS part is largely the same as in H6, except for one special register */
> +struct sunxi_mctl_com_reg {
> + u32 cr; /* 0x000 control register */
> + u8 reserved_0x004[4];   /* 0x004 */
> + u32 unk_0x008;  /* 0x008 */
> + u32 tmr;/* 0x00c timer register */
> + u8 reserved_0x010[4];   /* 0x010 */
> + u32 unk_0x014;  /* 0x014 */
> + u8 reserved_0x018[8];   /* 0x018 */
> + u32 maer0;  /* 0x020 master enable register 0 */
> + u32 maer1;  /* 0x024 master enable register 1 */
> + u32 maer2;  /* 0x028 master enable register 2 */
> + u8 reserved_0x02c[468]; /* 0x02c */
> + u32 bwcr;   /* 0x200 bandwidth control register */
> + u8 reserved_0x204[12];  /* 0x204 */
> + /*
> +  * The last master configured by BSP libdram is at 0x49x, so the
> +  * size of this struct array is set to 41 (0x29) now.
> +  */
> + struct {
> + u32 cfg0;   /* 0x0 */
> + u32 cfg1;   /* 0x4 */
> + u8 reserved_0x8[8]; /* 0x8 */
> + } master[41];   /* 0x210 + index * 0x10 */
> + u8 reserved_0x4a0[96];  /* 0x4a0 */
> + u32 unk_0x500;  /* 0x500 */
> +};
> +check_member(sunxi_mctl_com_reg, unk_0x500, 0x500);
> +
> +/*
> + * Controller registers seems to be the same or at least very similar
> + * to those in H6.
> + */
> +struct sunxi_mctl_ctl_reg {
> + u32 mstr;   /* 0x000 */
> + u32 statr;  /* 0x004 unused */
> + u32 mstr1;  /* 0x008 unused */
> + u32 unk_0x00c;  /* 0x00c */

This is clken (and the same on H6). It is obvious when looking at the
standby power-down sequence.

> + u32 mrctrl0;/* 0x010 unused */
> + u32 mrctrl1;/* 0x014 unused */
> + u32 mrstatr;/* 0x018 unused */
> + u32 mrctrl2;/* 0x01c unused */
> + u32 derateen;   /* 0x020 unused */
> + u32 derateint;  /* 0x024 unused */
> + u8 reserved_0x028[8];   /* 0x028 */
> + u32 pwrctl; /* 0x030 unused */
> + u32 pwrtmg; /* 0x034 unused */
> + u32 hwlpctl;/* 0x038 unused */
> + u8 reserved_0x03c[20];  /* 0x03c */
> + u32 rfshctl0;   /* 0x050 unused */
> + u32 rfshctl1;   /* 0x054 unused */
> + u8 reserved_0x058[8];   /* 0x05c */
> + u32 rfshctl3;   /* 0x060 */
> + u32 rfshtmg;/* 0x064 */
> + u8 reserved_0x068[104]; /* 0x068 */
> + u32 init[8];/* 0x0d0 */
> + u32 dimmctl;/* 0x0f0 unused */
> + u32 rankctl;

Re: [linux-sunxi] [PATCH 10/17] sunxi: add support for R_I2C on H616

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> This port is needed for communication with PMIC. SPL uses it to set DRAM
> voltage on H616 boards.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
>  board/sunxi/board.c| 4 
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index cdb7dbd5b8e5..de77bf638e21 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -220,6 +220,7 @@ enum sunxi_gpio_number {
>  #define SUN8I_A23_GPL_R_TWI  3
>  #define SUN8I_GPL_R_UART 2
>  #define SUN50I_GPL_R_TWI 2
> +#define SUN50I_H616_GPL_R_TWI3

The fact that I2C is at function 3 makes me suspicious that there is RSB
at function 2. Have you checked if that is the case?

Either way:

Reviewed-by: Samuel Holland 

>  #define SUN9I_GPN_R_RSB  3
>  
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 54ff9bc92396..727e8320318f 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -196,6 +196,10 @@ void i2c_init_board(void)
>   clock_twi_onoff(5, 1);
>   sunxi_gpio_set_cfgpin(SUNXI_GPL(8), SUN50I_GPL_R_TWI);
>   sunxi_gpio_set_cfgpin(SUNXI_GPL(9), SUN50I_GPL_R_TWI);
> +#elif CONFIG_MACH_SUN50I_H616
> + clock_twi_onoff(5, 1);
> + sunxi_gpio_set_cfgpin(SUNXI_GPL(0), SUN50I_H616_GPL_R_TWI);
> + sunxi_gpio_set_cfgpin(SUNXI_GPL(1), SUN50I_H616_GPL_R_TWI);
>  #else
>   clock_twi_onoff(5, 1);
>   sunxi_gpio_set_cfgpin(SUNXI_GPL(0), SUN8I_H3_GPL_R_TWI);
> 

-- 
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/0fffcaf4-93cd-6396-73b3-45fa40b69850%40sholland.org.

Re: [linux-sunxi] [PATCH 09/17] sunxi: add support for H616 uart0

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> This port is used for debug terminal on all known H616 boards.
> 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Samuel Holland 

-- 
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/64c791b0-814a-6135-3436-473902012450%40sholland.org.

Re: [linux-sunxi] [PATCH 08/17] sunxi: introduce support for H616 clocks

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> H616 has mostly the same clocks as H6 with some small differences. Just
> reuse H6 clocks for H616 and handle differences with macros.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  .../include/asm/arch-sunxi/clock_sun50i_h6.h   | 18 +-
>  arch/arm/mach-sunxi/clock_sun50i_h6.c  | 10 +-
>  2 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h 
> b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> index e83e84ab6cab..62abfc4ef6bd 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> @@ -230,6 +230,7 @@ struct sunxi_ccm_reg {
>  #define CCM_PLL1_CTRL_EN BIT(31)
>  #define CCM_PLL1_LOCK_EN BIT(29)
>  #define CCM_PLL1_LOCKBIT(28)
> +#define CCM_PLL1_OUT_EN  BIT(27)
>  #define CCM_PLL1_CLOCK_TIME_2(2 << 24)
>  #define CCM_PLL1_CTRL_P(p)   ((p) << 16)
>  #define CCM_PLL1_CTRL_N(n)   ((n) << 8)
> @@ -238,6 +239,7 @@ struct sunxi_ccm_reg {
>  #define CCM_PLL5_CTRL_EN BIT(31)
>  #define CCM_PLL5_LOCK_EN BIT(29)
>  #define CCM_PLL5_LOCKBIT(28)
> +#define CCM_PLL5_OUT_EN  BIT(27)
>  #define CCM_PLL5_CTRL_N(n)   ((n) << 8)
>  #define CCM_PLL5_CTRL_DIV1(div1) ((div1) << 0)
>  #define CCM_PLL5_CTRL_DIV2(div0) ((div0) << 1)
> @@ -252,7 +254,6 @@ struct sunxi_ccm_reg {
>  #define CCM_PLL6_CTRL_DIV1_MASK  (0x1 << 
> CCM_PLL6_CTRL_DIV1_SHIFT)
>  #define CCM_PLL6_CTRL_DIV2_SHIFT 1
>  #define CCM_PLL6_CTRL_DIV2_MASK  (0x1 << 
> CCM_PLL6_CTRL_DIV2_SHIFT)
> -#define CCM_PLL6_DEFAULT 0xa0006300
>  
>  /* cpu_axi bit field*/
>  #define CCM_CPU_AXI_MUX_MASK (0x3 << 24)
> @@ -262,6 +263,9 @@ struct sunxi_ccm_reg {
>  #define CCM_CPU_AXI_AXI_MASK 0x3
>  #define CCM_CPU_AXI_DEFAULT_FACTORS  0x301
>  
> +#ifdef CONFIG_MACH_SUN50I_H6
> +#define CCM_PLL6_DEFAULT 0xa0006300
> +
>  /* psi_ahb1_ahb2 bit field */
>  #define CCM_PSI_AHB1_AHB2_DEFAULT0x03000102
>  
> @@ -270,6 +274,18 @@ struct sunxi_ccm_reg {
>  
>  /* apb1 bit field */
>  #define CCM_APB1_DEFAULT 0x03000102
> +#elif CONFIG_MACH_SUN50I_H616
> +#define CCM_PLL6_DEFAULT 0xa8003100
> +
> +/* psi_ahb1_ahb2 bit field */
> +#define CCM_PSI_AHB1_AHB2_DEFAULT0x0302
> +
> +/* ahb3 bit field */
> +#define CCM_AHB3_DEFAULT 0x0302
> +
> +/* apb1 bit field */
> +#define CCM_APB1_DEFAULT 0x03000102
> +#endif
>  
>  /* apb2 bit field */
>  #define APB2_CLK_SRC_OSC24M  (0x0 << 24)
> diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c 
> b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> index 6bd466915c11..a4cc1b53728b 100644
> --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> @@ -68,6 +68,9 @@ void clock_set_pll1(unsigned int clk)
>  
>   /* clk = 24*n/p, p is ignored if clock is >288MHz */
>   writel(CCM_PLL1_CTRL_EN | CCM_PLL1_LOCK_EN | CCM_PLL1_CLOCK_TIME_2 |
> +#ifdef CONFIG_MACH_SUN50I_H616
> +CCM_PLL1_OUT_EN |
> +#endif
>  CCM_PLL1_CTRL_N(clk / 2400), >pll1_cfg);
>   while (!(readl(>pll1_cfg) & CCM_PLL1_LOCK)) {}
>  
> @@ -83,6 +86,11 @@ unsigned int clock_get_pll6(void)
>  {
>   struct sunxi_ccm_reg *const ccm =
>   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
> +#ifdef CONFIG_MACH_SUN50I_H6
> + int m = 4;
> +#else
> + int m = 2;
> +#endif

This looks like a good place for an IS_ENABLED ternary.

>   uint32_t rval = readl(>pll6_cfg);
>   int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT);
> @@ -91,7 +99,7 @@ unsigned int clock_get_pll6(void)
>   int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>
>   CCM_PLL6_CTRL_DIV2_SHIFT) + 1;
>   /* The register defines PLL6-4X, not plain PLL6 */

Now it is PLL6-2X or PLL6-4X.

With those adjustments:

Reviewed-by: Samuel Holland 

> - return 2400 / 4 * n / div1 / div2;
> + return 2400 / m * n / div1 / div2;
>  }
>  
>  int clock_twi_onoff(int port, int state)
> 

-- 
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/6144f8e0-622f-36fa-caee-bb9c539b2fba%40sholland.org.

Re: [linux-sunxi] [PATCH 07/17] sunxi: support loading with SPL > 32KB

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> From: Andre Przywara 
> 
> H616 supports and needs bigger SPL than 32 KiB, mostly due to big DRAM
> driver and need for PMIC configuration, which pull several drivers which
> are not needed otherwise.
> 
> Signed-off-by: Andre Przywara 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/mach-sunxi/board.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 7a8b303f233c..296efd615769 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -277,6 +277,14 @@ uint32_t sunxi_get_boot_device(void)
>  }
>  
>  #ifdef CONFIG_SPL_BUILD
> +static u32 sunxi_get_spl_size(void)
> +{
> + if (!is_boot0_magic(SPL_ADDR + 4)) /* eGON.BT0 */
> + return 32768;
In the context of the suggestion below, this case could return 0.

> +
> + return readl(SPL_ADDR + 0x10);
> +}
> +
>  /*
>   * The eGON SPL image can be located at 8KB or at 128KB into an SD card or
>   * an eMMC device. The boot source has bit 4 set in the latter case.
> @@ -286,6 +294,7 @@ uint32_t sunxi_get_boot_device(void)
>  unsigned long spl_mmc_get_uboot_raw_sector(struct mmc *mmc)

As a side note, the prototype for this function was changed in commit
cf0082559698 ("spl: mmc: Fix spl_mmc_get_uboot_raw_sector()
implementation"), but nobody noticed since it is not in a header.

>  {
>   unsigned long sector = CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR;
> + u32 spl_size = sunxi_get_spl_size();
>  
>   switch (sunxi_get_boot_source()) {
>   case SUNXI_BOOTED_FROM_MMC0_HIGH:
> @@ -294,6 +303,9 @@ unsigned long spl_mmc_get_uboot_raw_sector(struct mmc 
> *mmc)
>   break;
>   }
>  
> + if (spl_size > 32768)
> + sector += (spl_size - 32768) / 512;
> +

What I would suggest doing instead of this is setting
SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x40,
SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0x10, and then before the
switch statement doing:

sector = max(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR,
 spl_size / 512);

Not only does this get rid of the magic 32768 constant (which is
meaningless on new platforms), but it also works cleanly for eMMC boot
partitions (where there's no 0x10 sector offset).

>   return sector;
>  }
>  
> 

Cheers,
Samuel

-- 
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/ab1c65f0-2fec-5982-04f8-fb3b41e5c6aa%40sholland.org.

Re: [linux-sunxi] [PATCH 06/17] sunxi: Add support for I2C on H6 like SoCs

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> I2C support, especially R_I2C port, will be needed in future. Upcoming
> support for H616 will need R_I2C to adjust DRAM voltage.
> 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Samuel Holland 

-- 
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/5b30c0cc-1031-8a4a-ccfa-a2f500a75119%40sholland.org.

Re: [linux-sunxi] [PATCH 05/17] sunxi: prcm: Add memory map for H6 like SoCs

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> There was no need to have prcm definitions for H6 and similar SoCs till
> now. However, support R_I2C will be needed soon in SPL.
> 
> Move old definitions to prcm_sun6i.h and add new ones in prcm_sun50i.h.
> One of those files will be selected in common prcm.h based on defined
> macros.
> 
> This commit doesn't do any functional change.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/include/asm/arch-sunxi/prcm.h| 249 +-
>  arch/arm/include/asm/arch-sunxi/prcm_sun50i.h |  41 +++
>  arch/arm/include/asm/arch-sunxi/prcm_sun6i.h  | 247 +
>  3 files changed, 298 insertions(+), 239 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun50i.h
>  create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun6i.h
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h 
> b/arch/arm/include/asm/arch-sunxi/prcm.h
> index 767d1ff98d74..5106076f5e91 100644
> --- a/arch/arm/include/asm/arch-sunxi/prcm.h
> +++ b/arch/arm/include/asm/arch-sunxi/prcm.h
> @@ -1,247 +1,18 @@
>  /* SPDX-License-Identifier: GPL-2.0+ */
>  /*
> - * Sunxi A31 Power Management Unit register definition.
> + * (C) Copyright 2020 Jernej Skrabec 
>   *
> - * (C) Copyright 2013 Oliver Schinagl 
> - * http://linux-sunxi.org
> - * Allwinner Technology Co., Ltd. 
> - * Berg Xing 
> - * Tom Cubie 
> + * Sunxi platform prcm register definition.
>   */
>  
>  #ifndef _SUNXI_PRCM_H
>  #define _SUNXI_PRCM_H
>  
> -#define __PRCM_CPUS_CFG_PRE(n) (((n) & 0x3) << 4)
> -#define PRCM_CPUS_CFG_PRE_MASK __PRCM_CPUS_CFG_PRE(0x3)
> -#define __PRCM_CPUS_CFG_PRE_DIV(n) (((n) >> 1) - 1)
> -#define PRCM_CPUS_CFG_PRE_DIV(n) \
> - __PRCM_CPUS_CFG_PRE(__PRCM_CPUS_CFG_CLK_PRE(n))
> -#define __PRCM_CPUS_CFG_POST(n) (((n) & 0x1f) << 8)
> -#define PRCM_CPUS_CFG_POST_MASK __PRCM_CPUS_CFG_POST(0x1f)
> -#define __PRCM_CPUS_CFG_POST_DIV(n) ((n) - 1)
> -#define PRCM_CPUS_CFG_POST_DIV(n) \
> - __PRCM_CPUS_CFG_POST_DIV(__PRCM_CPUS_CFG_POST_DIV(n))
> -#define __PRCM_CPUS_CFG_CLK_SRC(n) (((n) & 0x3) << 16)
> -#define PRCM_CPUS_CFG_CLK_SRC_MASK __PRCM_CPUS_CFG_CLK_SRC(0x3)
> -#define __PRCM_CPUS_CFG_CLK_SRC_LOSC 0x0
> -#define __PRCM_CPUS_CFG_CLK_SRC_HOSC 0x1
> -#define __PRCM_CPUS_CFG_CLK_SRC_PLL6 0x2
> -#define __PRCM_CPUS_CFG_CLK_SRC_PDIV 0x3
> -#define PRCM_CPUS_CFG_CLK_SRC_LOSC \
> - __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_LOSC)
> -#define PRCM_CPUS_CFG_CLK_SRC_HOSC \
> - __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_HOSC)
> -#define PRCM_CPUS_CFG_CLK_SRC_PLL6 \
> - __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_PLL6)
> -#define PRCM_CPUS_CFG_CLK_SRC_PDIV \
> - __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_PDIV)
> -
> -#define __PRCM_APB0_RATIO(n) (((n) & 0x3) << 0)
> -#define PRCM_APB0_RATIO_DIV_MASK __PRCM_APB0_RATIO_DIV(0x3)
> -#define __PRCM_APB0_RATIO_DIV(n) (((n) >> 1) - 1)
> -#define PRCM_APB0_RATIO_DIV(n) \
> - __PRCM_APB0_RATIO(__PRCM_APB0_RATIO_DIV(n))
> -
> -#define PRCM_CPU_CFG_NEON_CLK_EN (0x1 << 0)
> -#define PRCM_CPU_CFG_CPU_CLK_EN (0x1 << 1)
> -
> -#define PRCM_APB0_GATE_PIO (0x1 << 0)
> -#define PRCM_APB0_GATE_IR (0x1 << 1)
> -#define PRCM_APB0_GATE_TIMER01 (0x1 << 2)
> -#define PRCM_APB0_GATE_P2WI (0x1 << 3)   /* sun6i */
> -#define PRCM_APB0_GATE_RSB (0x1 << 3)/* sun8i */
> -#define PRCM_APB0_GATE_UART (0x1 << 4)
> -#define PRCM_APB0_GATE_1WIRE (0x1 << 5)
> -#define PRCM_APB0_GATE_I2C (0x1 << 6)
> -
> -#define PRCM_APB0_RESET_PIO (0x1 << 0)
> -#define PRCM_APB0_RESET_IR (0x1 << 1)
> -#define PRCM_APB0_RESET_TIMER01 (0x1 << 2)
> -#define PRCM_APB0_RESET_P2WI (0x1 << 3)
> -#define PRCM_APB0_RESET_UART (0x1 << 4)
> -#define PRCM_APB0_RESET_1WIRE (0x1 << 5)
> -#define PRCM_APB0_RESET_I2C (0x1 << 6)
> -
> -#define PRCM_PLL_CTRL_PLL_BIAS (0x1 << 0)
> -#define PRCM_PLL_CTRL_HOSC_GAIN_ENH (0x1 << 1)
> -#define __PRCM_PLL_CTRL_USB_CLK_SRC(n) (((n) & 0x3) << 4)
> -#define PRCM_PLL_CTRL_USB_CLK_SRC_MASK \
> - __PRCM_PLL_CTRL_USB_CLK_SRC(0x3)
> -#define __PRCM_PLL_CTRL_USB_CLK_0 0x0
> -#define __PRCM_PLL_CTRL_USB_CLK_1 0x1
> -#define __PRCM_PLL_CTRL_USB_CLK_2 0x2
> -#define __PRCM_PLL_CTRL_USB_CLK_3 0x3
> -#define PRCM_PLL_CTRL_USB_CLK_0 \
> - __PRCM_PLL_CTRL_USB_CLK_SRC(__PRCM_PLL_CTRL_USB_CLK_0)
> -#define PRCM_PLL_CTRL_USB_CLK_1 \
> - __PRCM_PLL_CTRL_USB_CLK_SRC(__PRCM_PLL_CTRL_USB_CLK_1)
> -#define PRCM_PLL_CTRL_USB_CLK_2 \
> - __PRCM_PLL_CTRL_USB_CLK_SRC(__PRCM_PLL_CTRL_USB_CLK_2)
> -#define PRCM_PLL_CTRL_USB_CLK_3 \
> - __PRCM_PLL_CTRL_USB_CLK_SRC(__PRCM_PLL_CTRL_USB_CLK_3)
> -#define __PRCM_PLL_CTRL_INT_PLL_IN_SEL(n) (((n) & 0x3) << 12)
> -#define PRCM_PLL_CTRL_INT_PLL_IN_SEL_MASK \
> - __PRCM_PLL_CTRL_INT_PLL_IN_SEL(0x3)
> -#define PRCM_PLL_CTRL_INT_PLL_IN_SEL(n) \
> - __PRCM_PLL_CTRL_INT_PLL_IN_SEL(n)
> -#define __PRCM_PLL_CTRL_HOSC_CLK_SEL(n) (((n) & 0x3) << 20)
> -#define PRCM_PLL_CTRL_HOSC_CLK_SEL_MASK \
> - __PRCM_PLL_CTRL_HOSC_CLK_SEL(0x3)
> -#define 

Re: [linux-sunxi] [PATCH 04/17] i2c: mvtwsi: sunxi: update macro

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> While currently none of the newer Allwinner SoCs currently has I2C
> support implemented in U-Boot, this will change soon. mvtwsi driver is
> good as it is for them except one macro. Update it to be ready once I2C
> support lands for those SoCs.
> 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Samuel Holland 

-- 
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/8f61f690-6dfe-a0c2-c726-419dd1ea7f01%40sholland.org.

Re: [linux-sunxi] [PATCH 02/17] sunxi: Introduce common symbol for H6 like SoCs

[Samuel Holland]

On 1/3/21 3:26 AM, Jernej Skrabec wrote:
> It turns out that there are at least 2 other SoCs which have basically
> the same memory map, similar clocks and other features as H6. It's very
> likely that we'll see more such SoCs in the future. In order to ease
> porting to new SoCs and lower ifdef clutter, introduce common symbol for
> them.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  arch/arm/include/asm/arch-sunxi/boot0.h |  2 +-
>  arch/arm/include/asm/arch-sunxi/clock.h |  2 +-
>  arch/arm/include/asm/arch-sunxi/cpu.h   |  2 +-
>  arch/arm/include/asm/arch-sunxi/timer.h |  2 +-
>  arch/arm/mach-sunxi/Kconfig | 21 +
>  arch/arm/mach-sunxi/Makefile|  2 +-
>  arch/arm/mach-sunxi/board.c |  4 ++--
>  arch/arm/mach-sunxi/rmr_switch.S|  2 +-
>  common/spl/Kconfig  |  4 ++--
>  include/configs/sun50i.h|  2 +-
>  10 files changed, 24 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h 
> b/arch/arm/include/asm/arch-sunxi/boot0.h
> index 46d0f0666c2b..e8e8e38f0556 100644
> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
> @@ -39,7 +39,7 @@
>   .word   0xf57ff06f  // isb sy
>   .word   0xe320f003  // wfi
>   .word   0xeafd  // b   @wfi
> -#ifndef CONFIG_MACH_SUN50I_H6
> +#ifndef CONFIG_SUN50I_GEN_H6
>   .word   0x017000a0  // writeable RVBAR mapping address
>  #else
>   .word   0x09010040  // writeable RVBAR mapping address
> diff --git a/arch/arm/include/asm/arch-sunxi/clock.h 
> b/arch/arm/include/asm/arch-sunxi/clock.h
> index 5994130e6b54..cbbe5c7a1e68 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock.h
> @@ -16,7 +16,7 @@
>  /* clock control module regs definition */
>  #if defined(CONFIG_MACH_SUN8I_A83T)
>  #include 
> -#elif defined(CONFIG_MACH_SUN50I_H6)
> +#elif defined(CONFIG_SUN50I_GEN_H6)
>  #include 
>  #elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
>defined(CONFIG_MACH_SUN50I)
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h 
> b/arch/arm/include/asm/arch-sunxi/cpu.h
> index 8b57d24e2f0c..b08f2023748c 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
> @@ -8,7 +8,7 @@
>  
>  #if defined(CONFIG_MACH_SUN9I)
>  #include 
> -#elif defined(CONFIG_MACH_SUN50I_H6)
> +#elif defined(CONFIG_SUN50I_GEN_H6)
>  #include 
>  #else
>  #include 
> diff --git a/arch/arm/include/asm/arch-sunxi/timer.h 
> b/arch/arm/include/asm/arch-sunxi/timer.h
> index 6f138d04b806..bb5626d893bb 100644
> --- a/arch/arm/include/asm/arch-sunxi/timer.h
> +++ b/arch/arm/include/asm/arch-sunxi/timer.h
> @@ -76,7 +76,7 @@ struct sunxi_timer_reg {
>   struct sunxi_tgp tgp[4];
>   u8 res5[8];
>   u32 cpu_cfg;
> -#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
> +#elif defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6)
>   u8 res3[16];
>   struct sunxi_wdog wdog[5];  /* We have 5 watchdogs */
>  #endif
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 49ef217f08c0..1cf79bad7cf6 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -82,7 +82,7 @@ config SUN8I_RSB
>  config SUNXI_SRAM_ADDRESS
>   hex
>   default 0x1 if MACH_SUN9I || MACH_SUN50I || MACH_SUN50I_H5
> - default 0x2 if MACH_SUN50I_H6
> + default 0x2 if SUN50I_GEN_H6
>   default 0x0
>   ---help---
>   Older Allwinner SoCs have their mask boot ROM mapped just below 4GB,
> @@ -108,6 +108,15 @@ config SUNXI_GEN_SUN6I
>   separate ahb reset control registers, custom pmic bus, new style
>   watchdog, etc.
>  
> +config SUN50I_GEN_H6

The new memory map is also used for 32-bit SoCs V5 (sun8iw12p1) and
newer. So this is not sun50i-specific, and I'd suggest SUNXI_GEN_H6 (or
even SUNXI_GEN_H6_V5). It is unfortunate there appears to be no name for
this family.

> + bool
> + select FIT
> + select SPL_LOAD_FIT
> + select SUPPORT_SPL
> + ---help---
> + Select this for sunxi SoCs which have H6 like peripherals, clocks
> + and memory map.
> +
>  config SUNXI_DRAM_DW
>   bool
>   ---help---
> @@ -302,10 +311,7 @@ config MACH_SUN50I_H5
>  config MACH_SUN50I_H6
>   bool "sun50i (Allwinner H6)"
>   select ARM64
> - select SUPPORT_SPL
> - select FIT
>   select PHY_SUN4I_USB
> - select SPL_LOAD_FIT
>   select DRAM_SUN50I_H6

I would expect this to select SUN50I_GEN_H6.

>  endchoice
> @@ -540,7 +546,6 @@ config SYS_CLK_FREQ
>   default 81600 if MACH_SUN50I || MACH_SUN50I_H5
>   default 100800 if MACH_SUN8I
>   default 100800 if MACH_SUN9I
> - default 88800 if MACH_SUN50I_H6

Was this removal intentional? You later add a different value for H616 only.

>  config SYS_CONFIG_NAME
>  

[linux-sunxi] Re: [PATCH v3 03/10] irqchip/sun6i-r: Use a stacked irqchip driver

[Samuel Holland]

On 1/3/21 5:27 AM, Marc Zyngier wrote:
> On Sun, 03 Jan 2021 10:30:54 +,
> Samuel Holland  wrote:
>>
>> The R_INTC in the A31 and newer sun8i/sun50i SoCs is more similar to the
>> original sun4i interrupt controller than the sun7i/sun9i NMI controller.
>> It is used for two distinct purposes:
>>  - To control the trigger, latch, and mask for the NMI input pin
>>  - To provide the interrupt input for the ARISC coprocessor
>>
>> As this interrupt controller is not documented, information about it
>> comes from vendor-provided firmware blobs and from experimentation.
>>
>> Like the original sun4i interrupt controller, it has:
>>  - A VECTOR_REG at 0x00 (configurable via the BASE_ADDR_REG at 0x04)
>>  - A NMI_CTRL_REG, PENDING_REG, and ENABLE_REG as used by both the
>>sun4i and sunxi-nmi drivers
>>  - A MASK_REG at 0x50
>>  - A RESP_REG at 0x60
>>
>> Differences from the sun4i interrupt controller appear to be:
>>  - It only has one or two registers of each kind (max 32 or 64 IRQs)
>>  - Multiplexing logic is added to support additional inputs
>>  - There is no FIQ-related logic
>>  - There is no interrupt priority logic
>>
>> In order to fulfill its two purposes, this hardware block combines four
>> types of IRQs. First, the NMI pin is routed to the "IRQ 0" input on this
>> chip, with a trigger type controlled by the NMI_CTRL_REG. The "IRQ 0
>> pending" output from this chip, if enabled, is then routed to a SPI IRQ
>> input on the GIC. In other words, bit 0 of IRQ_ENABLE_REG *does* affect
>> the NMI IRQ seen at the GIC.
>>
>> The NMI is followed by a contiguous block of 15 "direct" (my name for
>> them) IRQ inputs that are connected in parallel to both R_INTC and the
>> GIC. Or in other words, these bits of IRQ_ENABLE_REG *do not* affect the
>> IRQs seen at the GIC.
>>
>> Following the direct IRQs are the ARISC's copy of banked IRQs for shared
>> peripherals. These are not relevant to Linux. The remaining IRQs are
>> connected to a multiplexer and provide access to the first (up to) 128
>> SPIs from the ARISC. This range of SPIs overlaps with the direct IRQs.
>>
>> Finally, the global "IRQ pending" output from R_INTC, after being masked
>> by MASK_REG and RESP_REG, is connected to the "external interrupt" input
>> of the ARISC CPU. This path is also irrelevant to Linux.
> 
> An ASCII-art version of this would help a lot, and would look good in
> the driver code...

There is this diagram which I forgot to include in the cover letter:

  https://linux-sunxi.org/images/5/5c/R_INTC.png

I can try to come up with some ASCII art.

>> Because of the 1:1 correspondence between R_INTC and GIC inputs, this is
>> a perfect scenario for using a stacked irqchip driver. We want to hook
>> into enabling/disabling IRQs to add more features to the GIC
>> (specifically to allow masking the NMI and setting its trigger type),
>> but we don't need to actually handle the IRQ in this driver.
>>
>> And since R_INTC is in the always-on power domain, and its output is
>> connected directly in to the power management coprocessor, a stacked
>> irqchip driver provides a simple way to add wakeup support to this set
>> of IRQs. That is the next patch; for now, just the NMI is moved over.
>>
>> To allow access to all multiplexed IRQs, this driver requires a new
>> binding where the interrupt number matches the GIC interrupt number.
>> (This moves the NMI number from 0 to 32 or 96, depending on the SoC.)
>> For simplicity, copy the three-cell GIC binding; this disambiguates
>> interrupt 0 in the old binding (the NMI) from interrupt 0 in the new
>> binding (SPI 0) by the number of cells.
>>
>> This commit mostly reverts commit 173bda53b340 ("irqchip/sunxi-nmi:
>> Support sun6i-a31-r-intc compatible").
>>
>> Signed-off-by: Samuel Holland 
>> ---
>>  arch/arm/mach-sunxi/Kconfig |   1 +
>>  arch/arm64/Kconfig.platforms|   1 +
>>  drivers/irqchip/Makefile|   1 +
>>  drivers/irqchip/irq-sun6i-r.c   | 267 
>>  drivers/irqchip/irq-sunxi-nmi.c |  26 +---
>>  5 files changed, 273 insertions(+), 23 deletions(-)
>>  create mode 100644 drivers/irqchip/irq-sun6i-r.c
>>
> 
> [...]
> 
>> diff --git a/drivers/irqchip/irq-sun6i-r.c b/drivers/irqchip/irq-sun6i-r.c
>> new file mode 100644
>> index ..7490ade7b254
>> --- /dev/null
>> +++ b/drivers/irqchip/irq-sun6i-r.c
>> @@ -0,0 +1,267 @@
>> +// SPDX-License-Identifier: GPL-2

[linux-sunxi] [PATCH net-next 5/5] net: stmmac: dwmac-sun8i: Add a shutdown callback

[Samuel Holland]

The Ethernet MAC and PHY are usually major consumers of power on boards
which may not be able to fully power off (that have no PMIC). Powering
down the MAC and internal PHY saves power while these boards are "off".

Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4638d4203af5..926e8d5e8963 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1282,6 +1282,15 @@ static int sun8i_dwmac_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static void sun8i_dwmac_shutdown(struct platform_device *pdev)
+{
+   struct net_device *ndev = platform_get_drvdata(pdev);
+   struct stmmac_priv *priv = netdev_priv(ndev);
+   struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
+
+   sun8i_dwmac_exit(pdev, gmac);
+}
+
 static const struct of_device_id sun8i_dwmac_match[] = {
{ .compatible = "allwinner,sun8i-h3-emac",
.data = _variant_h3 },
@@ -1302,6 +1311,7 @@ MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
 static struct platform_driver sun8i_dwmac_driver = {
.probe  = sun8i_dwmac_probe,
.remove = sun8i_dwmac_remove,
+   .shutdown = sun8i_dwmac_shutdown,
.driver = {
.name   = "dwmac-sun8i",
.pm = _pltfr_pm_ops,
-- 
2.26.2

-- 
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/20210103112542.35149-6-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next 3/5] net: stmmac: dwmac-sun8i: Use reset_control_reset

[Samuel Holland]

Use the appropriate function instead of reimplementing it,
and update the error message to match the code.

Signed-off-by: Samuel Holland 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 3c3d0b99d3e8..0e8d88417251 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -806,11 +806,9 @@ static int sun8i_dwmac_power_internal_phy(struct 
stmmac_priv *priv)
/* Make sure the EPHY is properly reseted, as U-Boot may leave
 * it at deasserted state, and thus it may fail to reset EMAC.
 */
-   reset_control_assert(gmac->rst_ephy);
-
-   ret = reset_control_deassert(gmac->rst_ephy);
+   ret = reset_control_reset(gmac->rst_ephy);
if (ret) {
-   dev_err(priv->device, "Cannot deassert internal phy\n");
+   dev_err(priv->device, "Cannot reset internal PHY\n");
clk_disable_unprepare(gmac->ephy_clk);
return ret;
}
-- 
2.26.2

-- 
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/20210103112542.35149-4-samuel%40sholland.org.

[linux-sunxi] [PATCH net-next 0/5] dwmac-sun8i cleanup and shutdown hook

[Samuel Holland]

These patches clean up some things I noticed while fixing suspend/resume
behavior. The first four are minor code improvements. The last one adds
a shutdown hook to minimize power consumption on boards without a PMIC.

Samuel Holland (5):
  net: stmmac: dwmac-sun8i: Return void from PHY unpower
  net: stmmac: dwmac-sun8i: Remove unnecessary PHY power check
  net: stmmac: dwmac-sun8i: Use reset_control_reset
  net: stmmac: dwmac-sun8i: Minor probe function cleanup
  net: stmmac: dwmac-sun8i: Add a shutdown callback

 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 31 ---
 1 file changed, 19 insertions(+), 12 deletions(-)

-- 
2.26.2

-- 
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/20210103112542.35149-1-samuel%40sholland.org.