Re: [PATCH 1/2] efi_loader: move load options to new module

2021-01-18 Thread Ilias Apalodimas
Hi Heinrich,

Overall the patch and idea seem fine.
Would it make sense to name the file differently?
Something similar to what I did on my initrd  patches, i.e efi_helper.c, so we
can start adding helper functions that have a wider usage?


Thanks
/Ilias

On Fri, Jan 15, 2021 at 07:02:49PM +0100, Heinrich Schuchardt wrote:
> Move all load options related functions to a new module. So that they can
> be compiled independently.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_load_options.c | 151 ++
>  1 file changed, 151 insertions(+)
>  create mode 100644 lib/efi_loader/efi_load_options.c
> 
> diff --git a/lib/efi_loader/efi_load_options.c 
> b/lib/efi_loader/efi_load_options.c
> new file mode 100644
> index 00..9f0e25b6e9
> --- /dev/null
> +++ b/lib/efi_loader/efi_load_options.c
> @@ -0,0 +1,151 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + *  EFI boot manager
> + *
> + *  Copyright (c) 2017 Rob Clark
> + */
> +
> +#define LOG_CATEGORY LOGC_EFI
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +//#include 
> +#include 
> +
> +/**
> + * efi_set_load_options() - set the load options of a loaded image
> + *
> + * @handle:  the image handle
> + * @load_options_size:   size of load options
> + * @load_options:pointer to load options
> + * Return:   status code
> + */
> +efi_status_t efi_set_load_options(efi_handle_t handle,
> +   efi_uintn_t load_options_size,
> +   void *load_options)
> +{
> + struct efi_loaded_image *loaded_image_info;
> + efi_status_t ret;
> +
> + ret = EFI_CALL(systab.boottime->open_protocol(
> + handle,
> + _guid_loaded_image,
> + (void **)_image_info,
> + efi_root, NULL,
> + EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL));
> + if (ret != EFI_SUCCESS)
> + return EFI_INVALID_PARAMETER;
> +
> + loaded_image_info->load_options = load_options;
> + loaded_image_info->load_options_size = load_options_size;
> +
> + return EFI_CALL(systab.boottime->close_protocol(handle,
> + _guid_loaded_image,
> + efi_root, NULL));
> +}
> +
> +/**
> + * efi_deserialize_load_option() - parse serialized data
> + *
> + * Parse serialized data describing a load option and transform it to the
> + * efi_load_option structure.
> + *
> + * @lo:  pointer to target
> + * @data:serialized data
> + * @size:size of the load option, on return size of the optional data
> + * Return:   status code
> + */
> +efi_status_t efi_deserialize_load_option(struct efi_load_option *lo, u8 
> *data,
> +  efi_uintn_t *size)
> +{
> + efi_uintn_t len;
> +
> + len = sizeof(u32);
> + if (*size < len + 2 * sizeof(u16))
> + return EFI_INVALID_PARAMETER;
> + lo->attributes = get_unaligned_le32(data);
> + data += len;
> + *size -= len;
> +
> + len = sizeof(u16);
> + lo->file_path_length = get_unaligned_le16(data);
> + data += len;
> + *size -= len;
> +
> + lo->label = (u16 *)data;
> + len = u16_strnlen(lo->label, *size / sizeof(u16) - 1);
> + if (lo->label[len])
> + return EFI_INVALID_PARAMETER;
> + len = (len + 1) * sizeof(u16);
> + if (*size < len)
> + return EFI_INVALID_PARAMETER;
> + data += len;
> + *size -= len;
> +
> + len = lo->file_path_length;
> + if (*size < len)
> + return EFI_INVALID_PARAMETER;
> + lo->file_path = (struct efi_device_path *)data;
> + if (efi_dp_check_length(lo->file_path, len) < 0)
> + return EFI_INVALID_PARAMETER;
> + data += len;
> + *size -= len;
> +
> + lo->optional_data = data;
> +
> + return EFI_SUCCESS;
> +}
> +
> +/**
> + * efi_serialize_load_option() - serialize load option
> + *
> + * Serialize efi_load_option structure into byte stream for Boot.
> + *
> + * @data:buffer for serialized data
> + * @lo:  load option
> + * Return:   size of allocated buffer
> + */
> +unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 
> **data)
> +{
> + unsigned long label_len;
> + unsigned long size;
> + u8 *p;
> +
> + label_len = (u16_strlen(lo->label) + 1) * sizeof(u16);
> +
> + /* total size */
> + size = sizeof(lo->attributes);
> + size += sizeof(lo->file_path_length);
> + size += label_len;
> + size += lo->file_path_length;
> + if (lo->optional_data)
> + size += (utf8_utf16_strlen((const char *)lo->optional_data)
> ++ 1) * sizeof(u16);
> + p = malloc(size);
> + if (!p)
> + return 0;
> +
> +  

RE: [PATCH 4/4] board: keymile: add support for seli8 design based on nxp ls102x soc

2021-01-18 Thread Priyanka Jain (OSS)
>-Original Message-
>From: U-Boot  On Behalf Of Aleksandar
>Gerasimovski
>Sent: Wednesday, January 13, 2021 9:51 PM
>To: u-boot@lists.denx.de
>Cc: Valentin Longchamp ; Holger
>Brunck ; Rainer Boschung
>; Matteo Ghidoni
>
>Subject: [PATCH 4/4] board: keymile: add support for seli8 design based on nxp
>ls102x soc
>
Please trim subject to 60 characters

>The SELI8 design is a new tdm service unit card for Hitachi-Powergrids XMC and
>FOX product lines.
>
>It is based on NXP LS1021 SoC and it provides following interfaces:
> - IFC interface for NOR, NAND and external FPGA's
> - 1 x RGMII ETH for debug purposes
> - 2 x SGMII ETH for management communication via back-plane
> - 1 x uQE HDLC for management communication via back-plane
> - 1 x I2C for peripheral devices
> - 1 x SPI for peripheral devices
> - 1 x UART for debug logging
>
>It is foreseen that the design will be later re-used for another XMC and FOX
>service cards with similar SoC requirements.
>
>Signed-off-by: Rainer Boschung 
>Signed-off-by: Matteo Ghidoni 
>Signed-off-by: Aleksandar Gerasimovski powergrids.com>
>---
> arch/arm/Kconfig|  19 ++
> arch/arm/dts/Makefile   |   2 +
> arch/arm/dts/ls1021a-pg-wcom-seli8.dts  | 111 +
> board/keymile/Kconfig   |  23 +-
> board/keymile/common/ivm.c  |  19 +-
> board/keymile/pg-wcom-ls102xa/Kconfig   |  19 ++
> board/keymile/pg-wcom-ls102xa/MAINTAINERS   |  10 +
> board/keymile/pg-wcom-ls102xa/Makefile  |  11 +
> board/keymile/pg-wcom-ls102xa/ddr.c |  90 +++
> board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 160 
> configs/pg_wcom_seli8_defconfig |  63 +
> include/configs/km/pg-wcom-ls102xa.h| 309
>
> include/configs/pg-wcom-seli8.h |  45 
> 13 files changed, 870 insertions(+), 11 deletions(-)  create mode 100644
>arch/arm/dts/ls1021a-pg-wcom-seli8.dts
> create mode 100644 board/keymile/pg-wcom-ls102xa/Kconfig
> create mode 100644 board/keymile/pg-wcom-ls102xa/MAINTAINERS
> create mode 100644 board/keymile/pg-wcom-ls102xa/Makefile
> create mode 100644 board/keymile/pg-wcom-ls102xa/ddr.c
> create mode 100644 board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
> create mode 100644 configs/pg_wcom_seli8_defconfig  create mode 100644
>include/configs/km/pg-wcom-ls102xa.h
> create mode 100644 include/configs/pg-wcom-seli8.h
>


Regards
Priyank


RE: [PATCH 3/4] board: keymile: common: fix pnvramaddr and varaddr address calculation

2021-01-18 Thread Priyanka Jain (OSS)



>-Original Message-
>From: U-Boot  On Behalf Of Aleksandar
>Gerasimovski
>Sent: Wednesday, January 13, 2021 9:51 PM
>To: u-boot@lists.denx.de
>Cc: Valentin Longchamp ; Holger
>Brunck ; Rainer Boschung
>; Matteo Ghidoni
>
>Subject: [PATCH 3/4] board: keymile: common: fix pnvramaddr and varaddr
>address calculation
>
Please trim subject line to 60 characters
>Take into account SDRAM_BASE address when calculating pnvramaddr and
>varaddr offsets.
>Up to now Keymile designs had SDRAM_BASE equal to zero and the offsets where
>calculated correctly, this fix is for the upcoming designs that have SDRAM_BASE
>different then zero.
>
>Signed-off-by: Aleksandar Gerasimovski powergrids.com>


Regards
Priyanka


RE: [v2 01/33] gpio: mpc8xxx_gpio: fix a bug on ls1046ardb

2021-01-18 Thread Priyanka Jain (OSS)
>-Original Message-
>From: U-Boot  On Behalf Of Biwen Li
>Sent: Tuesday, December 8, 2020 2:29 PM
>To: Priyanka Jain 
>Cc: Jiafei Pan ; u-boot@lists.denx.de; Xiaobo Xie
>; Biwen Li 
>Subject: [v2 01/33] gpio: mpc8xxx_gpio: fix a bug on ls1046ardb
>
>From: Biwen Li 
>
Please provide summary of changes this patch is doing in patch description.
Also ensure to update copyright (year) for all the files if required.
>Fix a bug as belows,
>=> gpio status -a
>"Synchronous Abort" handler, esr 0x9661
>elr: 82047964 lr : 82047960 (reloc)
>elr: fbd72964 lr : fbd72960
>x0 :  x1 : 000a
>x2 : 0020 x3 : 0001
>x4 :  x5 : 0030
>x6 : 0020 x7 : 0002
>x8 : ffe0 x9 : 0008
>x10: 0010 x11: 0006
>x12: 0001869f x13: 0230
>x14: fbc23e9c x15: 
>
>Signed-off-by: Biwen Li 
>---


Regards
Priyanka


Re: [PATCH 1/1] dm: core: describe uclass_root_s

2021-01-18 Thread Heinrich Schuchardt
Am 19. Januar 2021 01:49:28 MEZ schrieb Simon Glass :
>Hi Bin,
>
>On Sat, 16 Jan 2021 at 03:59, Bin Meng  wrote:
>>
>> On Sat, Jan 16, 2021 at 6:13 PM Heinrich Schuchardt
> wrote:
>> >
>> > make htmldocs creates a warning:
>> >
>> > ./include/asm-generic/global_data.h:443:
>> > warning: Function parameter or member 'uclass_root_s'
>> > not described in 'global_data'
>> >
>> > Correct the member descriptions.
>> >
>> > Fixes: 8a715530bb1f ("dm: core: Allow the uclass list to move")
>> > Signed-off-by: Heinrich Schuchardt 
>> > ---
>> >  include/asm-generic/global_data.h | 8 
>> >  1 file changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/include/asm-generic/global_data.h
>b/include/asm-generic/global_data.h
>> > index efa09a1943..9fa9a17003 100644
>> > --- a/include/asm-generic/global_data.h
>> > +++ b/include/asm-generic/global_data.h
>> > @@ -198,13 +198,13 @@ struct global_data {
>> >  */
>> > struct udevice *dm_root_f;
>> > /**
>> > -* @uclass_root: head of core tree
>> > +* @uclass_root_s: static head of core tree, if uclasses
>are in
>> > +* read-only memory and cannot be adjusted to use
>@uclass_root as a
>> > +* list head.
>> >  */
>> > struct list_head uclass_root_s;
>>
>> _s stands for static?
>>
>> If so, I suspect the comment was just the opposite?
>
>Yes. I inserted the new variable but did not move the comment...
>

Hello Simon,

do you mean the patch is wrong?

What should the comments look like?

Best regards

Heinrich


>
>>
>> > /**
>> > -* @uclass_root: pointer to head of core tree, if uclasses
>are in
>> > -* read-only memory and cannot be adjusted to use
>@uclass_root as a
>> > -* list head.
>> > +* @uclass_root: pointer to the head of core tree
>> >  */
>> > struct list_head *uclass_root;
>> >  # if CONFIG_IS_ENABLED(OF_PLATDATA)
>> > --
>>
>
>Regards,
>Simon



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

2021-01-18 Thread 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


RE: [PATCH 2/2] arm64: dts: imx8mm-beacon: Resync imx8mm-beacon-som with 5.11-rc4

2021-01-18 Thread Peng Fan
> Subject: [PATCH 2/2] arm64: dts: imx8mm-beacon: Resync
> imx8mm-beacon-som with 5.11-rc4
> 
> In order to support the QSPI chip on the SOM, the Flexspi bus needs to be
> configured to talk with the SPI chip.
> Resync the som device tree with 5.11-rc4
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/dts/imx8mm-beacon-som.dtsi
> b/arch/arm/dts/imx8mm-beacon-som.dtsi
> index b88c3c99b0..d897913537 100644
> --- a/arch/arm/dts/imx8mm-beacon-som.dtsi
> +++ b/arch/arm/dts/imx8mm-beacon-som.dtsi
> @@ -4,6 +4,11 @@
>   */
> 
>  / {
> + aliases {
> + rtc0 = 
> + rtc1 = _rtc;

Acked-by: Peng Fan 

Just have a question here, why you have two RTC here?

> + };
> +
>   usdhc1_pwrseq: usdhc1_pwrseq {
>   compatible = "mmc-pwrseq-simple";
>   pinctrl-names = "default";
> @@ -24,6 +29,18 @@
>   cpu-supply = <_reg>;
>  };
> 
> +_1 {
> + cpu-supply = <_reg>;
> +};
> +
> +_2 {
> + cpu-supply = <_reg>;
> +};
> +
> +_3 {
> + cpu-supply = <_reg>;
> +};
> +
>   {
>   operating-points-v2 = <_opp_table>;
> 
> @@ -63,6 +80,22 @@
>   };
>  };
> 
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_flexspi>;
> + status = "okay";
> +
> + flash@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <8000>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> +};
> +
>   {
>   clock-frequency = <40>;
>   pinctrl-names = "default";
> @@ -78,6 +111,10 @@
>   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
>   rohm,reset-snvs-powered;
> 
> + #clock-cells = <0>;
> + clocks = <_32k 0>;
> + clock-output-names = "clk-32k-out";
> +
>   regulators {
>   buck1_reg: BUCK1 {
>   regulator-name = "buck1";
> @@ -191,7 +228,7 @@
>   reg = <0x50>;
>   };
> 
> - rtc@51 {
> + rtc: rtc@51 {
>   compatible = "nxp,pcf85263";
>   reg = <0x51>;
>   };
> @@ -258,155 +295,166 @@
>  };
> 
>   {
> - pinctrl_fec1: fec1grp {
> - fsl,pins = <
> - MX8MM_IOMUXC_ENET_MDC_ENET1_MDC 0x3
> - MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO   0x3
> - MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3   0x1f
> - MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2   0x1f
> - MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1   0x1f
> - MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0   0x1f
> - MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3   0x91
> - MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2   0x91
> - MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1   0x91
> - MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0   0x91
> - MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC   0x1f
> - MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC   0x91
> -
>   MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
> - MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL
>   0x1f
> - MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO220x19
> - >;
> - };
> + pinctrl_fec1: fec1grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_ENET_MDC_ENET1_MDC 0x3
> + MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO   0x3
> + MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3   0x1f
> + MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2   0x1f
> + MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1   0x1f
> + MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0   0x1f
> + MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3   0x91
> + MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2   0x91
> + MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1   0x91
> + MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0   0x91
> + MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC   0x1f
> + MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC   0x91
> + MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL
>   0x91
> + MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL
>   0x1f
> + MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO220x19
> + >;
> + };
> 
> - pinctrl_i2c1: i2c1grp {
> - fsl,pins = <
> - MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL
>   0x41c3
> - MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA
>   0x41c3
> - >;
> - };
> + pinctrl_i2c1: i2c1grp {
> + 

RE: [PATCH 1/2] imx8mm_beacon: Enable QSPI Support

2021-01-18 Thread Peng Fan
> Subject: [PATCH 1/2] imx8mm_beacon: Enable QSPI Support
> 
> There is a QSPI chip connected to the FSPI.  Enable the defconfig to support
> it.
> 
> Signed-off-by: Adam Ford 

Reviewed-by: Peng Fan 
> 
> diff --git a/configs/imx8mm_beacon_defconfig
> b/configs/imx8mm_beacon_defconfig index 49d5453078..2970e5dc71
> 100644
> --- a/configs/imx8mm_beacon_defconfig
> +++ b/configs/imx8mm_beacon_defconfig
> @@ -41,6 +41,7 @@ CONFIG_CMD_GPIO=y
>  CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
>  CONFIG_CMD_PART=y
> +CONFIG_CMD_SPI=y
>  CONFIG_CMD_DHCP=y
>  CONFIG_CMD_MII=y
>  CONFIG_CMD_PING=y
> @@ -78,6 +79,14 @@ CONFIG_MMC_HS400_ES_SUPPORT=y
> CONFIG_MMC_HS400_SUPPORT=y
> CONFIG_SPL_MMC_HS400_SUPPORT=y  CONFIG_FSL_USDHC=y
> +CONFIG_MTD=y
> +CONFIG_DM_MTD=y
> +CONFIG_DM_SPI_FLASH=y
> +CONFIG_SF_DEFAULT_MODE=0x0
> +CONFIG_SF_DEFAULT_SPEED=1000
> +CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_STMICRO=y
> +CONFIG_SPI_FLASH_MTD=y
>  CONFIG_PHYLIB=y
>  CONFIG_PHY_ATHEROS=y
>  CONFIG_DM_ETH=y
> @@ -102,7 +111,6 @@ CONFIG_DM_SERIAL=y
>  CONFIG_MXC_UART=y
>  CONFIG_SPI=y
>  CONFIG_DM_SPI=y
> -CONFIG_SPI_MEM=y
>  CONFIG_NXP_FSPI=y
>  CONFIG_SYSRESET=y
>  CONFIG_SPL_SYSRESET=y
> --
> 2.25.1



RE: [PATCH 1/3] clk: imx: Add ECSPI to iMX8MN

2021-01-18 Thread Peng Fan
> Subject: [PATCH 1/3] clk: imx: Add ECSPI to iMX8MN
> 
> Add ECSPI clock entries to iMX8MN clock driver. Only make those entries
> available in case SPI support in U-Boot is enabled at all to conserve space, 
> esp.
> in SPL.
> 
> Signed-off-by: Marek Vasut 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> ---
>  drivers/clk/imx/clk-imx8mn.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
> index e29d902544c..e398d7de02a 100644
> --- a/drivers/clk/imx/clk-imx8mn.c
> +++ b/drivers/clk/imx/clk-imx8mn.c
> @@ -105,6 +105,20 @@ static const char *imx8mn_usdhc1_sels[] =
> {"clock-osc-24m", "sys_pll1_400m", "sy  static const char
> *imx8mn_usdhc2_sels[] = {"clock-osc-24m", "sys_pll1_400m",
> "sys_pll1_800m", "sys_pll2_500m",
>  "sys_pll3_out", "sys_pll1_266m",
> "audio_pll2_out", "sys_pll1_100m", };
> 
> +#if CONFIG_IS_ENABLED(DM_SPI)
> +static const char *imx8mn_ecspi1_sels[] = {"osc_24m", "sys_pll2_200m",
> "sys_pll1_40m",
> +"sys_pll1_160m", "sys_pll1_800m",
> "sys_pll3_out",
> +"sys_pll2_250m", "audio_pll2_out", };
> +
> +static const char *imx8mn_ecspi2_sels[] = {"osc_24m", "sys_pll2_200m",
> "sys_pll1_40m",
> +"sys_pll1_160m", "sys_pll1_800m",
> "sys_pll3_out",
> +"sys_pll2_250m", "audio_pll2_out", };
> +
> +static const char *imx8mn_ecspi3_sels[] = {"osc_24m", "sys_pll2_200m",
> "sys_pll1_40m",
> +"sys_pll1_160m", "sys_pll1_800m",
> "sys_pll3_out",
> +"sys_pll2_250m", "audio_pll2_out", 
> }; #endif
> +
>  static const char *imx8mn_i2c1_sels[] = {"clock-osc-24m", "sys_pll1_160m",
> "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
>"video_pll1_out", "audio_pll2_out",
> "sys_pll1_133m", };
> 
> @@ -440,6 +454,21 @@ static int imx8mn_clk_probe(struct udevice *dev)
>  base + 0x40a0, 0));
>  #endif
> 
> +#if CONFIG_IS_ENABLED(DM_SPI)
> + clk_dm(IMX8MN_CLK_ECSPI1,
> +imx8m_clk_composite("ecspi1", imx8mn_ecspi1_sels, base +
> 0xb280));
> + clk_dm(IMX8MN_CLK_ECSPI2,
> +imx8m_clk_composite("ecspi2", imx8mn_ecspi2_sels, base +
> 0xb300));
> + clk_dm(IMX8MN_CLK_ECSPI3,
> +imx8m_clk_composite("ecspi3", imx8mn_ecspi3_sels, base +
> 0xc180));
> + clk_dm(IMX8MN_CLK_ECSPI1_ROOT,
> +imx_clk_gate4("ecspi1_root_clk", "ecspi1", base + 0x4070, 0));
> + clk_dm(IMX8MN_CLK_ECSPI2_ROOT,
> +imx_clk_gate4("ecspi2_root_clk", "ecspi2", base + 0x4080, 0));
> + clk_dm(IMX8MN_CLK_ECSPI3_ROOT,
> +imx_clk_gate4("ecspi3_root_clk", "ecspi3", base + 0x4090, 0));
> +#endif
> +
>   return 0;
>  }

Reviewed-by: Peng Fan 

> 
> --
> 2.29.2



[PATCH] sunxi: Properly check for SATAPWR and MACPWR

2021-01-18 Thread Andre Przywara
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.

Reported-by: Peter Robinson 
Signed-off-by: Andre Przywara 
---
 board/sunxi/board.c | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 4f058952b5b..a0b5778b3bc 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -265,18 +265,28 @@ int board_init(void)
if (ret)
return ret;
 
-#ifdef CONFIG_SATAPWR
-   satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
-   gpio_request(satapwr_pin, "satapwr");
-   gpio_direction_output(satapwr_pin, 1);
-   /* Give attached sata device time to power-up to avoid link timeouts */
-   mdelay(500);
-#endif
-#ifdef CONFIG_MACPWR
-   macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
-   gpio_request(macpwr_pin, "macpwr");
-   gpio_direction_output(macpwr_pin, 1);
-#endif
+   /* strcmp() would look better, but doesn't get optimised away. */
+   if (CONFIG_SATAPWR[0]) {
+   satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
+   if (satapwr_pin >= 0) {
+   gpio_request(satapwr_pin, "satapwr");
+   gpio_direction_output(satapwr_pin, 1);
+
+   /*
+* Give the attached SATA device time to power-up
+* to avoid link timeouts
+*/
+   mdelay(500);
+   }
+   }
+
+   if (CONFIG_MACPWR[0]) {
+   macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
+   if (macpwr_pin >= 0) {
+   gpio_request(macpwr_pin, "macpwr");
+   gpio_direction_output(macpwr_pin, 1);
+   }
+   }
 
 #ifdef CONFIG_DM_I2C
/*
-- 
2.17.5



Re: [PATCH] sunxi: don't define MACPWR and SATAPWR to empty strings

2021-01-18 Thread Andre Przywara
On 18/01/2021 00:18, Peter Robinson wrote:

Hi Peter,

> There's checks in board/sunxi/board.c if either MACPWR or SATAPWR are
> defined and they are defined by default to a empty string which means
> on vast majority of AllWinner boards when they're not required the
> code is still run and with SATAPWR we even get an unnecessary 500ms
> delay booting. So let's not define a default for these options so the
> code is only run for boards that need it.
> 
> Signed-off-by: Peter Robinson 
> ---
>  arch/arm/mach-sunxi/Kconfig | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 49ef217f08..a566e10315 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -578,7 +578,6 @@ config OLD_SUNXI_KERNEL_COMPAT
>  
>  config MACPWR
>   string "MAC power pin"
> - default ""

But that doesn't really help, does it? The kernel Kconfig documentation
doesn't mention this explicitly, but the implicit default for strings is
actually "", so I still see CONFIG_MACPWR="" in my .config, even after
your patch. And consequently I see all the code still being executed.

I made a patch the does the check in the board.c, I would be grateful if
you could test this.

Cheers,
Andre

>   help
> Set the pin used to power the MAC. This takes a string in
> the format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of
> port H. @@ -969,7 +968,6 @@ endchoice
>  
>  config SATAPWR
>   string "SATA power pin"
> - default ""
>   help
> Set the pins used to power the SATA. This takes a string
> in the format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of
> 



Re: [PATCH v4 01/23] mips: dts: switch to board defines for dtb for mtmips

2021-01-18 Thread Weijie Gao
On Mon, 2021-01-18 at 22:43 +0100, Daniel Schwierzeck wrote:
> Am Montag, den 18.01.2021, 15:54 +0800 schrieb Weijie Gao:
> > On Fri, 2020-11-27 at 21:19 +0100, Daniel Schwierzeck wrote:
> > > Am Donnerstag, den 12.11.2020, 16:35 +0800 schrieb Weijie Gao:
> > > > Previous the dts files for gardena-smart-gateway-mt7688 and
> > > > linkit-smart-7688 are set to be built when mtmips is selected.
> > > > 
> > > > This can lead to a compilation error if another soc is added to this 
> > > > arch
> > > > with different dtsi files.
> > > > 
> > > > So it's better to build the dtb only if their board is selected.
> > > > 
> > > > Reviewed-by: Stefan Roese 
> > > > Signed-off-by: Weijie Gao 
> > > > ---
> > > > v4 changes: none
> > > > v3 changes: none
> > > > v2 changes: none
> > > > ---
> > > >  arch/mips/dts/Makefile | 5 ++---
> > > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > > 
> > > > 
> > > 
> > > series applied to u-boot-mips/next, thanks.
> > > 
> > 
> > Hi Daniel,
> > 
> > Gentle ping
> > 
> > I'm just curious when can the patch series be merged into u-boot/master?
> > 
> 
> Hi Weijie,
> 
> thanks for the reminder, I missed the opening of the merge window ;) 
> 
> I rebased the MIPS next branch and triggered all CI builds. If all is
> ok, I'll prepare a pull request.
> 

got it. thanks.


Re: [PATCH 1/1] dm: core: describe uclass_root_s

2021-01-18 Thread Simon Glass
Hi Bin,

On Sat, 16 Jan 2021 at 03:59, Bin Meng  wrote:
>
> On Sat, Jan 16, 2021 at 6:13 PM Heinrich Schuchardt  
> wrote:
> >
> > make htmldocs creates a warning:
> >
> > ./include/asm-generic/global_data.h:443:
> > warning: Function parameter or member 'uclass_root_s'
> > not described in 'global_data'
> >
> > Correct the member descriptions.
> >
> > Fixes: 8a715530bb1f ("dm: core: Allow the uclass list to move")
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  include/asm-generic/global_data.h | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/asm-generic/global_data.h 
> > b/include/asm-generic/global_data.h
> > index efa09a1943..9fa9a17003 100644
> > --- a/include/asm-generic/global_data.h
> > +++ b/include/asm-generic/global_data.h
> > @@ -198,13 +198,13 @@ struct global_data {
> >  */
> > struct udevice *dm_root_f;
> > /**
> > -* @uclass_root: head of core tree
> > +* @uclass_root_s: static head of core tree, if uclasses are in
> > +* read-only memory and cannot be adjusted to use @uclass_root as a
> > +* list head.
> >  */
> > struct list_head uclass_root_s;
>
> _s stands for static?
>
> If so, I suspect the comment was just the opposite?

Yes. I inserted the new variable but did not move the comment...


>
> > /**
> > -* @uclass_root: pointer to head of core tree, if uclasses are in
> > -* read-only memory and cannot be adjusted to use @uclass_root as a
> > -* list head.
> > +* @uclass_root: pointer to the head of core tree
> >  */
> > struct list_head *uclass_root;
> >  # if CONFIG_IS_ENABLED(OF_PLATDATA)
> > --
>

Regards,
Simon


Re: Invitation: Regular U-Boot video call (Tuesday 19th)

2021-01-18 Thread Simon Glass
Hi Bin,

On Sun, 17 Jan 2021 at 21:41, Bin Meng  wrote:
>
> Hi Simon,
>
> On Sat, Jan 16, 2021 at 3:24 PM Peng Fan  wrote:
> >
> > Hi Simon,
> >
> > > Subject: Re: Invitation: Regular U-Boot video call (Tuesday 19th)
> > >
> > > Hi Peng,
> > >
> > > On Thu, 14 Jan 2021 at 18:33, Peng Fan  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > > Subject: Invitation: Regular U-Boot video call (Tuesday 19th)
> > > > >
> > > > > Hi,
> > > > >
> > > > > (This has been discussed for a while now so I thought I would just
> > > > > try it)
> > > > >
> > > > > As an experiment I'd like to set up a regular 30-minute U-Boot call
> > > > > for people to discuss features, bugs, patches, etc.
> > > > >
> > > > > The meeting notes and details are here[1].
> > > >
> > > > The url is blocked by China. Do you have a direct google meet link, not 
> > > > using
> > > bit.ly?
> > > > I am in UTC + 8 timezone, not sure I am able to join, but please invite 
> > > > me.
> > >
> > > Yes the link is here:
> > >
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.g
> > > oogle.com%2Fdocument%2Fd%2F1YBOMsbM19uSFyoJWnt7-PsOLBaevzQUg
> > > V-hiR88a5-o%2Feditdata=04%7C01%7Cpeng.fan%40nxp.com%7Cee2d
> > > 255017d84f89a04308d8b95f0c8a%7C686ea1d3bc2b4c6fa92cd99c5c301635
> > > %7C0%7C0%7C637463165315330931%7CUnknown%7CTWFpbGZsb3d8eyJW
> > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> > > 1000sdata=R7G%2B4iXtS%2F5qndSYHJ7L%2FzwmWfMJ5%2B%2FAWB
> > > RW1x2dB0s%3Dreserved=0
> > >
> > > I don't know why it would be blocked in China. Can you access that one?
> >
> > I could access this one and including the meet link using NXP VPN.
>
> Sorry I did the wrong conversion before. So the meeting time is 0:30
> am UTC +8. I am afraid I could not join. Not sure if Peng could stay
> that late :)

That is more early than late! Anyway let's see if we end up doing
something in the middle of the night in Europe, which might work for
you.

Regards,
Simon


[PATCH 3/3] spi: imx: Use clock framework if enabled

2021-01-18 Thread Marek Vasut
In case the clock framework is enabled, enable the SPI controller clock
and obtain max frequency from the clock framework.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Stefano Babic 
---
 drivers/spi/mxc_spi.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 849808fb916..3377200d24f 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -617,8 +618,19 @@ static int mxc_spi_probe(struct udevice *bus)
if (mxcs->base == FDT_ADDR_T_NONE)
return -ENODEV;
 
+#if CONFIG_IS_ENABLED(CLK)
+   struct clk clk;
+   ret = clk_get_by_index(bus, 0, );
+   if (ret)
+   return ret;
+
+   clk_enable();
+
+   mxcs->max_hz = clk_get_rate();
+#else
mxcs->max_hz = fdtdec_get_int(blob, node, "spi-max-frequency",
  2000);
+#endif
 
return 0;
 }
-- 
2.29.2



[PATCH 2/3] spi: imx: Define register bits in the driver

2021-01-18 Thread Marek Vasut
The CSPI/ECSPI register bits do not differ between newer SoCs, instead
of having multiple copies of the same thing for each iMX SoC, define
the bits in the driver.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Stefano Babic 
---
 arch/arm/include/asm/arch-mx25/imx-regs.h | 30 -
 arch/arm/include/asm/arch-mx31/imx-regs.h | 31 -
 arch/arm/include/asm/arch-mx35/imx-regs.h | 30 -
 arch/arm/include/asm/arch-mx5/imx-regs.h  | 36 ---
 arch/arm/include/asm/arch-mx6/imx-regs.h  | 36 ---
 arch/arm/include/asm/arch-mx7/imx-regs.h  | 37 ---
 drivers/spi/mxc_spi.c | 76 +++
 7 files changed, 76 insertions(+), 200 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 5d0974f3283..57809697c1a 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -269,18 +269,6 @@ struct epit_regs {
u32 cnr;/* Counter register */
 };
 
-/* CSPI registers */
-struct cspi_regs {
-   u32 rxdata;
-   u32 txdata;
-   u32 ctrl;
-   u32 intr;
-   u32 dma;
-   u32 stat;
-   u32 period;
-   u32 test;
-};
-
 #endif
 
 #define ARCH_MXC
@@ -508,24 +496,6 @@ struct cspi_regs {
 /*
  * CSPI register definitions
  */
-#define MXC_CSPI
-#define MXC_CSPICTRL_EN(1 << 0)
-#define MXC_CSPICTRL_MODE  (1 << 1)
-#define MXC_CSPICTRL_XCH   (1 << 2)
-#define MXC_CSPICTRL_SMC   (1 << 3)
-#define MXC_CSPICTRL_POL   (1 << 4)
-#define MXC_CSPICTRL_PHA   (1 << 5)
-#define MXC_CSPICTRL_SSCTL (1 << 6)
-#define MXC_CSPICTRL_SSPOL (1 << 7)
-#define MXC_CSPICTRL_CHIPSELECT(x) (((x) & 0x3) << 12)
-#define MXC_CSPICTRL_BITCOUNT(x)   (((x) & 0xfff) << 20)
-#define MXC_CSPICTRL_DATARATE(x)   (((x) & 0x7) << 16)
-#define MXC_CSPICTRL_TC(1 << 7)
-#define MXC_CSPICTRL_RXOVF (1 << 6)
-#define MXC_CSPICTRL_MAXBITS   0xfff
-#define MXC_CSPIPERIOD_32KHZ   (1 << 15)
-#define MAX_SPI_BYTES  4
-
 #define MXC_SPI_BASE_ADDRESSES \
IMX_CSPI1_BASE, \
IMX_CSPI2_BASE, \
diff --git a/arch/arm/include/asm/arch-mx31/imx-regs.h 
b/arch/arm/include/asm/arch-mx31/imx-regs.h
index 9e271d6ea2e..566db549ec6 100644
--- a/arch/arm/include/asm/arch-mx31/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx31/imx-regs.h
@@ -39,17 +39,6 @@ struct clock_control_regs {
u32 pdr2;
 };
 
-struct cspi_regs {
-   u32 rxdata;
-   u32 txdata;
-   u32 ctrl;
-   u32 intr;
-   u32 dma;
-   u32 stat;
-   u32 period;
-   u32 test;
-};
-
 /* IIM control registers */
 struct iim_regs {
u32 iim_stat;
@@ -889,26 +878,6 @@ struct esdc_regs {
 /*
  * CSPI register definitions
  */
-#define MXC_CSPI
-#define MXC_CSPICTRL_EN(1 << 0)
-#define MXC_CSPICTRL_MODE  (1 << 1)
-#define MXC_CSPICTRL_XCH   (1 << 2)
-#define MXC_CSPICTRL_SMC   (1 << 3)
-#define MXC_CSPICTRL_POL   (1 << 4)
-#define MXC_CSPICTRL_PHA   (1 << 5)
-#define MXC_CSPICTRL_SSCTL (1 << 6)
-#define MXC_CSPICTRL_SSPOL (1 << 7)
-#define MXC_CSPICTRL_CHIPSELECT(x) (((x) & 0x3) << 24)
-#define MXC_CSPICTRL_BITCOUNT(x)   (((x) & 0x1f) << 8)
-#define MXC_CSPICTRL_DATARATE(x)   (((x) & 0x7) << 16)
-#define MXC_CSPICTRL_TC(1 << 8)
-#define MXC_CSPICTRL_RXOVF (1 << 6)
-#define MXC_CSPICTRL_MAXBITS   0x1f
-
-#define MXC_CSPIPERIOD_32KHZ   (1 << 15)
-#define MAX_SPI_BYTES  4
-
-
 #define MXC_SPI_BASE_ADDRESSES \
0x43fa4000, \
0x5001, \
diff --git a/arch/arm/include/asm/arch-mx35/imx-regs.h 
b/arch/arm/include/asm/arch-mx35/imx-regs.h
index 8ee0754c8e5..35090047c70 100644
--- a/arch/arm/include/asm/arch-mx35/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx35/imx-regs.h
@@ -170,24 +170,6 @@
 /*
  * CSPI register definitions
  */
-#define MXC_CSPI
-#define MXC_CSPICTRL_EN(1 << 0)
-#define MXC_CSPICTRL_MODE  (1 << 1)
-#define MXC_CSPICTRL_XCH   (1 << 2)
-#define MXC_CSPICTRL_SMC   (1 << 3)
-#define MXC_CSPICTRL_POL   (1 << 4)
-#define MXC_CSPICTRL_PHA   (1 << 5)
-#define MXC_CSPICTRL_SSCTL (1 << 6)
-#define MXC_CSPICTRL_SSPOL (1 << 7)
-#define MXC_CSPICTRL_CHIPSELECT(x) (((x) & 0x3) << 12)
-#define MXC_CSPICTRL_BITCOUNT(x)   (((x) & 0xfff) << 20)
-#define MXC_CSPICTRL_DATARATE(x)   (((x) & 0x7) << 16)
-#define MXC_CSPICTRL_TC(1 << 7)
-#define MXC_CSPICTRL_RXOVF (1 << 6)
-#define MXC_CSPICTRL_MAXBITS   0xfff
-#define MXC_CSPIPERIOD_32KHZ   (1 << 15)
-#define MAX_SPI_BYTES  4
-
 #define MXC_SPI_BASE_ADDRESSES \
0x43fa4000, \
0x5001,
@@ -280,18 +262,6 @@ struct gpt_regs {
u32 counter;/* counter */
 };
 
-/* CSPI registers */
-struct cspi_regs {
-   u32 rxdata;
-   u32 txdata;
-   u32 ctrl;
-   u32 intr;
-   u32 dma;
-   u32 stat;
-   u32 period;
-   u32 test;
-};
-
 struct 

[PATCH 1/3] clk: imx: Add ECSPI to iMX8MN

2021-01-18 Thread Marek Vasut
Add ECSPI clock entries to iMX8MN clock driver. Only make those entries
available in case SPI support in U-Boot is enabled at all to conserve
space, esp. in SPL.

Signed-off-by: Marek Vasut 
Cc: Peng Fan 
Cc: Stefano Babic 
---
 drivers/clk/imx/clk-imx8mn.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
index e29d902544c..e398d7de02a 100644
--- a/drivers/clk/imx/clk-imx8mn.c
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -105,6 +105,20 @@ static const char *imx8mn_usdhc1_sels[] = 
{"clock-osc-24m", "sys_pll1_400m", "sy
 static const char *imx8mn_usdhc2_sels[] = {"clock-osc-24m", "sys_pll1_400m", 
"sys_pll1_800m", "sys_pll2_500m",
   "sys_pll3_out", "sys_pll1_266m", 
"audio_pll2_out", "sys_pll1_100m", };
 
+#if CONFIG_IS_ENABLED(DM_SPI)
+static const char *imx8mn_ecspi1_sels[] = {"osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+  "sys_pll1_160m", "sys_pll1_800m", 
"sys_pll3_out",
+  "sys_pll2_250m", "audio_pll2_out", };
+
+static const char *imx8mn_ecspi2_sels[] = {"osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+  "sys_pll1_160m", "sys_pll1_800m", 
"sys_pll3_out",
+  "sys_pll2_250m", "audio_pll2_out", };
+
+static const char *imx8mn_ecspi3_sels[] = {"osc_24m", "sys_pll2_200m", 
"sys_pll1_40m",
+  "sys_pll1_160m", "sys_pll1_800m", 
"sys_pll3_out",
+  "sys_pll2_250m", "audio_pll2_out", };
+#endif
+
 static const char *imx8mn_i2c1_sels[] = {"clock-osc-24m", "sys_pll1_160m", 
"sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
 "video_pll1_out", "audio_pll2_out", 
"sys_pll1_133m", };
 
@@ -440,6 +454,21 @@ static int imx8mn_clk_probe(struct udevice *dev)
   base + 0x40a0, 0));
 #endif
 
+#if CONFIG_IS_ENABLED(DM_SPI)
+   clk_dm(IMX8MN_CLK_ECSPI1,
+  imx8m_clk_composite("ecspi1", imx8mn_ecspi1_sels, base + 
0xb280));
+   clk_dm(IMX8MN_CLK_ECSPI2,
+  imx8m_clk_composite("ecspi2", imx8mn_ecspi2_sels, base + 
0xb300));
+   clk_dm(IMX8MN_CLK_ECSPI3,
+  imx8m_clk_composite("ecspi3", imx8mn_ecspi3_sels, base + 
0xc180));
+   clk_dm(IMX8MN_CLK_ECSPI1_ROOT,
+  imx_clk_gate4("ecspi1_root_clk", "ecspi1", base + 0x4070, 0));
+   clk_dm(IMX8MN_CLK_ECSPI2_ROOT,
+  imx_clk_gate4("ecspi2_root_clk", "ecspi2", base + 0x4080, 0));
+   clk_dm(IMX8MN_CLK_ECSPI3_ROOT,
+  imx_clk_gate4("ecspi3_root_clk", "ecspi3", base + 0x4090, 0));
+#endif
+
return 0;
 }
 
-- 
2.29.2



[PATCH] net: fec: Get rid of FEC_ENET_ENABLE_[TR]XC_DELAY

2021-01-18 Thread Marek Vasut
The FEC_ENET_ENABLE_.XC_DELAY setting is only used by one system which
supports OF control, correctly set the rgmii-id PHY mode in the DT and
then determine whether or not to enable the FEC RXC/TXC internal delay
based on the PHY mode.

Signed-off-by: Marek Vasut 
Cc: Oleksandr Suvorov 
Cc: Stefano Babic 
Cc: Ramon Fried 
---
 arch/arm/dts/fsl-imx8qm-apalis.dts  |  2 +-
 arch/arm/dts/fsl-imx8qxp-apalis.dts |  2 +-
 drivers/net/fec_mxc.c   | 14 ++
 include/configs/apalis-imx8.h   |  3 ---
 include/configs/apalis-imx8x.h  |  3 ---
 5 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/arch/arm/dts/fsl-imx8qm-apalis.dts 
b/arch/arm/dts/fsl-imx8qm-apalis.dts
index 5187b794527..0d8d3b3e8e8 100644
--- a/arch/arm/dts/fsl-imx8qm-apalis.dts
+++ b/arch/arm/dts/fsl-imx8qm-apalis.dts
@@ -503,7 +503,7 @@
pinctrl-0 = <_fec1>;
fsl,magic-packet;
phy-handle = <>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-reset-duration = <10>;
phy-reset-gpios = < 11 1>;
status = "okay";
diff --git a/arch/arm/dts/fsl-imx8qxp-apalis.dts 
b/arch/arm/dts/fsl-imx8qxp-apalis.dts
index 6bd231b2834..9cb3d3a809b 100644
--- a/arch/arm/dts/fsl-imx8qxp-apalis.dts
+++ b/arch/arm/dts/fsl-imx8qxp-apalis.dts
@@ -229,7 +229,7 @@
pinctrl-0 = <_fec1>;
fsl,magic-packet;
phy-handle = <>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-id";
phy-reset-duration = <10>;
phy-reset-post-delay = <150>;
phy-reset-gpios = < 4 GPIO_ACTIVE_LOW>;
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index bb55be9a267..73fc5f4c903 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -507,15 +507,13 @@ static int fec_open(struct eth_device *edev)
writel(readl(>eth->ecntrl) | FEC_ECNTRL_ETHER_EN,
   >eth->ecntrl);
 
-#ifdef FEC_ENET_ENABLE_TXC_DELAY
-   writel(readl(>eth->ecntrl) | FEC_ECNTRL_TXC_DLY,
-  >eth->ecntrl);
-#endif
+   if (fec->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+   fec->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+   setbits_le32(>eth->ecntrl, FEC_ECNTRL_TXC_DLY);
 
-#ifdef FEC_ENET_ENABLE_RXC_DELAY
-   writel(readl(>eth->ecntrl) | FEC_ECNTRL_RXC_DLY,
-  >eth->ecntrl);
-#endif
+   if (fec->interface == PHY_INTERFACE_MODE_RGMII_ID ||
+   fec->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+   setbits_le32(>eth->ecntrl, FEC_ECNTRL_RXC_DLY);
 
 #if defined(CONFIG_MX25) || defined(CONFIG_MX53) || defined(CONFIG_MX6SL)
udelay(100);
diff --git a/include/configs/apalis-imx8.h b/include/configs/apalis-imx8.h
index db4e9011c0b..81441d7770f 100644
--- a/include/configs/apalis-imx8.h
+++ b/include/configs/apalis-imx8.h
@@ -21,9 +21,6 @@
 #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
 
 /* Networking */
-#define FEC_QUIRK_ENET_MAC
-#define FEC_ENET_ENABLE_TXC_DELAY
-
 #define CONFIG_TFTP_TSIZE
 
 #define CONFIG_IPADDR  192.168.10.2
diff --git a/include/configs/apalis-imx8x.h b/include/configs/apalis-imx8x.h
index db31c210f50..90bbeb926d3 100644
--- a/include/configs/apalis-imx8x.h
+++ b/include/configs/apalis-imx8x.h
@@ -25,9 +25,6 @@
 #define CONFIG_NETMASK 255.255.255.0
 #define CONFIG_SERVERIP192.168.10.1
 
-#define FEC_ENET_ENABLE_TXC_DELAY
-#define FEC_ENET_ENABLE_RXC_DELAY
-
 #define MEM_LAYOUT_ENV_SETTINGS \
"kernel_addr_r=0x8028\0" \
"fdt_addr_r=0x8310\0" \
-- 
2.29.2



[PATCH 3/3] spi: fsl_qspi: apply the same settings for LS1088 as LS208x

2021-01-18 Thread Mathew McBride
The LS1088 requires the same QUADSPI_QURIK_BASE_INTERNAL
workaround as the LS208x and also has a 64 byte TX buffer.

With the previous settings SPI-NAND reads over AHB were
corrupted.

Fixes: 91afd36f3802 ("spi: Transform the FSL QuadSPI driver to use the SPI MEM 
API")
Signed-off-by: Mathew McBride 
---
 drivers/spi/fsl_qspi.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 2a1f3a0c44..f965301d6a 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -259,14 +259,6 @@ static const struct fsl_qspi_devtype_data ls1021a_data = {
.little_endian = false,
 };
 
-static const struct fsl_qspi_devtype_data ls1088a_data = {
-   .rxfifo = SZ_128,
-   .txfifo = SZ_128,
-   .ahb_buf_size = SZ_1K,
-   .quirks = QUADSPI_QUIRK_TKT253890,
-   .little_endian = true,
-};
-
 static const struct fsl_qspi_devtype_data ls2080a_data = {
.rxfifo = SZ_128,
.txfifo = SZ_64,
@@ -877,7 +869,7 @@ static const struct udevice_id fsl_qspi_ids[] = {
{ .compatible = "fsl,imx7d-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,imx7ulp-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,ls1021a-qspi", .data = (ulong)_data, },
-   { .compatible = "fsl,ls1088a-qspi", .data = (ulong)_data, },
+   { .compatible = "fsl,ls1088a-qspi", .data = (ulong)_data, },
{ .compatible = "fsl,ls2080a-qspi", .data = (ulong)_data, },
{ }
 };
-- 
2.30.0



[PATCH 2/3] spi: fsl_qspi: Ensure width is respected in spi-mem operations

2021-01-18 Thread Mathew McBride
Adapted from kernel commit b0177aca7aea
From: Michael Walle 

Make use of a core helper to ensure the desired width is respected
when calling spi-mem operators.

Otherwise only the SPI controller will be matched with the flash chip,
which might lead to wrong widths. Also consider the width specified by
the user in the device tree.

Fixes: 91afd36f38 ("spi: Add a driver for the Freescale/NXP QuadSPI controller")
Signed-off-by: Michael Walle 
Link: https://lore.kernel.org/r/20200114154613.8195-1-mich...@walle.cc
Signed-off-by: Mark Brown 
Signed-off-by: Mathew McBride  [adapt for U-Boot]
---
 drivers/spi/fsl_qspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 8bc7038a82..2a1f3a0c44 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -409,7 +409,7 @@ static bool fsl_qspi_supports_op(struct spi_slave *slave,
op->data.nbytes > q->devtype_data->txfifo)
return false;
 
-   return true;
+   return spi_mem_default_supports_op(slave, op);
 }
 
 static void fsl_qspi_prepare_lut(struct fsl_qspi *q,
-- 
2.30.0



[PATCH 1/3] mem: spi-mem: define spi_mem_default_supports_op

2021-01-18 Thread Mathew McBride
spi_mem_default_supports_op is used internally by controller
drivers to verify operation semantics are correct.

Signed-off-by: Mathew McBride 
---
 include/spi-mem.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/spi-mem.h b/include/spi-mem.h
index ca0f55c8fd..92c640dabe 100644
--- a/include/spi-mem.h
+++ b/include/spi-mem.h
@@ -216,6 +216,10 @@ int spi_controller_dma_map_mem_op_data(struct 
spi_controller *ctlr,
 void spi_controller_dma_unmap_mem_op_data(struct spi_controller *ctlr,
  const struct spi_mem_op *op,
  struct sg_table *sg);
+
+bool spi_mem_default_supports_op(struct spi_mem *mem,
+const struct spi_mem_op *op);
+
 #else
 static inline int
 spi_controller_dma_map_mem_op_data(struct spi_controller *ctlr,
@@ -231,6 +235,12 @@ spi_controller_dma_unmap_mem_op_data(struct spi_controller 
*ctlr,
 struct sg_table *sg)
 {
 }
+
+bool spi_mem_default_supports_op(struct spi_mem *mem,
+const struct spi_mem_op *op)
+{
+   return false;
+}
 #endif /* CONFIG_SPI_MEM */
 #endif /* __UBOOT__ */
 
-- 
2.30.0



[PATCH 0/3] Fixes for SPI-NAND issues on LS1088A

2021-01-18 Thread Mathew McBride
This patchset resolves issues seen when using SPI-NAND
with the LS1088A's qspi controller.

The main issue seen is data corruption when reading SPI-NAND,
due to a controller quirk not being applied. Using the same
settings as the LS2088A (the bigger brother of LS1088A) solves
this issue.

In the course of debugging the above issue, it was found
that the fsl_qspi driver was not correctly reporting the operation
width (single/dual/quad) configured for the device in DTS.
(e.g I configured my device for single-lane reads only
but quad operations were being issued)

A fix for this issue is already present in Linux and can be
adapted for U-Boot, providing a missing export for
spi_mem_default_supports_op is added.

Mathew McBride (3):
  mem: spi-mem: define spi_mem_default_supports_op
  spi: fsl_qspi: Ensure width is respected in spi-mem operations
  spi: fsl_qspi: apply the same settings for LS1088 as LS208x

 drivers/spi/fsl_qspi.c | 12 ++--
 include/spi-mem.h  | 10 ++
 2 files changed, 12 insertions(+), 10 deletions(-)

-- 
2.30.0



Re: [PATCH 04/15] gpio: Rename dm_gpio_get_dir_flags() to dm_gpio_get_flags()

2021-01-18 Thread Pratyush Yadav
On 15/01/21 07:04AM, Simon Glass wrote:
> This function can be used to get any flags, not just direction flags.
> Rename it to avoid confusion.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/gpio/gpio-uclass.c |  2 +-
>  include/asm-generic/gpio.h |  4 ++--
>  test/dm/gpio.c | 12 ++--
>  3 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index 83d3cf0a6b3..864a9003245 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -682,7 +682,7 @@ int dm_gpio_set_dir(struct gpio_desc *desc)
>   return _dm_gpio_update_flags(desc, desc->flags);
>  }
>  
> -int dm_gpio_get_dir_flags(struct gpio_desc *desc, ulong *flagsp)
> +int dm_gpio_get_flags(struct gpio_desc *desc, ulong *flagsp)
>  {
>   struct udevice *dev = desc->dev;
>   int ret, value;
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index 48e042dc44b..5ecb73c138d 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -685,7 +685,7 @@ int dm_gpio_set_dir(struct gpio_desc *desc);
>  int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong flags);
>  
>  /**
> - * dm_gpio_get_dir_flags() - Get direction flags
> + * dm_gpio_get_flags() - Get direction flags

s/Get direction flags/Get flags/

With this fixed,

Reviewed-by: Pratyush Yadav 

-- 
Regards,
Pratyush Yadav
Texas Instruments India


Re: [PATCH 03/15] dm: gpio: Rename get_dir_flags() method to get_flags()

2021-01-18 Thread Pratyush Yadav
On 15/01/21 07:04AM, Simon Glass wrote:
> It is more useful to be able to read all the flags, not just the direction
> ones. In fact this is what the STM32 driver does. Update the method name
> to reflect this.
> 
> Tweak the docs a little and use 'flagsp' as the return argument, as is
> common in driver model, to indicate it returns a value.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/gpio/gpio-uclass.c  | 30 +++---
>  drivers/gpio/sandbox.c  |  8 
>  drivers/gpio/stm32_gpio.c   |  8 
>  drivers/pinctrl/pinctrl-stmfx.c |  8 
>  include/asm-generic/gpio.h  | 13 +++--
>  5 files changed, 34 insertions(+), 33 deletions(-)
> 

Reviewed-by: Pratyush Yadav 

-- 
Regards,
Pratyush Yadav
Texas Instruments India


Re: [PATCH v4 01/23] mips: dts: switch to board defines for dtb for mtmips

2021-01-18 Thread Daniel Schwierzeck
Am Montag, den 18.01.2021, 15:54 +0800 schrieb Weijie Gao:
> On Fri, 2020-11-27 at 21:19 +0100, Daniel Schwierzeck wrote:
> > Am Donnerstag, den 12.11.2020, 16:35 +0800 schrieb Weijie Gao:
> > > Previous the dts files for gardena-smart-gateway-mt7688 and
> > > linkit-smart-7688 are set to be built when mtmips is selected.
> > > 
> > > This can lead to a compilation error if another soc is added to this arch
> > > with different dtsi files.
> > > 
> > > So it's better to build the dtb only if their board is selected.
> > > 
> > > Reviewed-by: Stefan Roese 
> > > Signed-off-by: Weijie Gao 
> > > ---
> > > v4 changes: none
> > > v3 changes: none
> > > v2 changes: none
> > > ---
> > >  arch/mips/dts/Makefile | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > 
> > 
> > series applied to u-boot-mips/next, thanks.
> > 
> 
> Hi Daniel,
> 
> Gentle ping
> 
> I'm just curious when can the patch series be merged into u-boot/master?
> 

Hi Weijie,

thanks for the reminder, I missed the opening of the merge window ;) 

I rebased the MIPS next branch and triggered all CI builds. If all is
ok, I'll prepare a pull request.

-- 
- Daniel



[PATCH 2/2] arm64: dts: imx8mm-beacon: Resync imx8mm-beacon-som with 5.11-rc4

2021-01-18 Thread Adam Ford
In order to support the QSPI chip on the SOM, the Flexspi bus
needs to be configured to talk with the SPI chip.
Resync the som device tree with 5.11-rc4

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/imx8mm-beacon-som.dtsi 
b/arch/arm/dts/imx8mm-beacon-som.dtsi
index b88c3c99b0..d897913537 100644
--- a/arch/arm/dts/imx8mm-beacon-som.dtsi
+++ b/arch/arm/dts/imx8mm-beacon-som.dtsi
@@ -4,6 +4,11 @@
  */
 
 / {
+   aliases {
+   rtc0 = 
+   rtc1 = _rtc;
+   };
+
usdhc1_pwrseq: usdhc1_pwrseq {
compatible = "mmc-pwrseq-simple";
pinctrl-names = "default";
@@ -24,6 +29,18 @@
cpu-supply = <_reg>;
 };
 
+_1 {
+   cpu-supply = <_reg>;
+};
+
+_2 {
+   cpu-supply = <_reg>;
+};
+
+_3 {
+   cpu-supply = <_reg>;
+};
+
  {
operating-points-v2 = <_opp_table>;
 
@@ -63,6 +80,22 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_flexspi>;
+   status = "okay";
+
+   flash@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   spi-max-frequency = <8000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   };
+};
+
  {
clock-frequency = <40>;
pinctrl-names = "default";
@@ -78,6 +111,10 @@
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
rohm,reset-snvs-powered;
 
+   #clock-cells = <0>;
+   clocks = <_32k 0>;
+   clock-output-names = "clk-32k-out";
+
regulators {
buck1_reg: BUCK1 {
regulator-name = "buck1";
@@ -191,7 +228,7 @@
reg = <0x50>;
};
 
-   rtc@51 {
+   rtc: rtc@51 {
compatible = "nxp,pcf85263";
reg = <0x51>;
};
@@ -258,155 +295,166 @@
 };
 
  {
-   pinctrl_fec1: fec1grp {
-   fsl,pins = <
-   MX8MM_IOMUXC_ENET_MDC_ENET1_MDC 0x3
-   MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO   0x3
-   MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3   0x1f
-   MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2   0x1f
-   MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1   0x1f
-   MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0   0x1f
-   MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3   0x91
-   MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2   0x91
-   MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1   0x91
-   MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0   0x91
-   MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC   0x1f
-   MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC   0x91
-   MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 
0x91
-   MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 
0x1f
-   MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO220x19
-   >;
-   };
+   pinctrl_fec1: fec1grp {
+   fsl,pins = <
+   MX8MM_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+   MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO   0x3
+   MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3   0x1f
+   MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2   0x1f
+   MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1   0x1f
+   MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0   0x1f
+   MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3   0x91
+   MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2   0x91
+   MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1   0x91
+   MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0   0x91
+   MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC   0x1f
+   MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC   0x91
+   MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+   MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+   MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO220x19
+   >;
+   };
 
-   pinctrl_i2c1: i2c1grp {
-   fsl,pins = <
-   MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL  
0x41c3
-   MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA  
0x41c3
-   >;
-   };
+   pinctrl_i2c1: i2c1grp {
+   fsl,pins = <
+   MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL  0x41c3
+   MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA  0x41c3
+   >;
+   };
 
-   pinctrl_i2c3: i2c3grp {
-

[PATCH 1/2] imx8mm_beacon: Enable QSPI Support

2021-01-18 Thread Adam Ford
There is a QSPI chip connected to the FSPI.  Enable the defconfig
to support it.

Signed-off-by: Adam Ford 

diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
index 49d5453078..2970e5dc71 100644
--- a/configs/imx8mm_beacon_defconfig
+++ b/configs/imx8mm_beacon_defconfig
@@ -41,6 +41,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
+CONFIG_CMD_SPI=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
@@ -78,6 +79,14 @@ CONFIG_MMC_HS400_ES_SUPPORT=y
 CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_SPL_MMC_HS400_SUPPORT=y
 CONFIG_FSL_USDHC=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SF_DEFAULT_MODE=0x0
+CONFIG_SF_DEFAULT_SPEED=1000
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_DM_ETH=y
@@ -102,7 +111,6 @@ CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-CONFIG_SPI_MEM=y
 CONFIG_NXP_FSPI=y
 CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
-- 
2.25.1



Re: [PATCH 02/15] dm: gpio: Rename set_dir_flags() method to update_flags()

2021-01-18 Thread Pratyush Yadav
Hi Simon,

> Subject: [PATCH 02/15] dm: gpio: Rename set_dir_flags() method to 
> update_flags()

Why not call it set_flags()? Matches up nicely with get_flags() in 
03/15.

On 15/01/21 07:04AM, Simon Glass wrote:
> The current method is a misnomer since it is also used (e.g. by stm32) to
> update pull settings and open source/open drain.
> 
> Rename it and expand the documentation to cover a few more details.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/gpio/gpio-uclass.c  | 16 
>  drivers/gpio/sandbox.c  |  6 +++---
>  drivers/gpio/stm32_gpio.c   |  6 +++---
>  drivers/pinctrl/pinctrl-stmfx.c |  6 +++---
>  include/asm-generic/gpio.h  | 30 --
>  test/dm/gpio.c  |  8 
>  6 files changed, 45 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index e84b68db772..0862a28bf86 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -619,7 +619,7 @@ static int check_dir_flags(ulong flags)
>   return 0;
>  }
>  
> -static int _dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong flags)
> +static int _dm_gpio_update_flags(struct gpio_desc *desc, ulong flags)
>  {
>   struct udevice *dev = desc->dev;
>   struct dm_gpio_ops *ops = gpio_get_ops(dev);
> @@ -637,9 +637,9 @@ static int _dm_gpio_set_dir_flags(struct gpio_desc *desc, 
> ulong flags)
>   return ret;
>   }
>  
> - /* GPIOD_ are directly managed by driver in set_dir_flags*/
> - if (ops->set_dir_flags) {
> - ret = ops->set_dir_flags(dev, desc->offset, flags);
> + /* GPIOD_ are directly managed by driver in update_flags */
> + if (ops->update_flags) {
> + ret = ops->update_flags(dev, desc->offset, flags);
>   } else {
>   if (flags & GPIOD_IS_OUT) {
>   ret = ops->direction_output(dev, desc->offset,
> @@ -666,7 +666,7 @@ int dm_gpio_set_dir_flags(struct gpio_desc *desc, ulong 
> flags)
>  
>   /* combine the requested flags (for IN/OUT) and the descriptor flags */
>   flags |= desc->flags;
> - ret = _dm_gpio_set_dir_flags(desc, flags);
> + ret = _dm_gpio_update_flags(desc, flags);
>  
>   return ret;
>  }
> @@ -679,7 +679,7 @@ int dm_gpio_set_dir(struct gpio_desc *desc)
>   if (ret)
>   return ret;
>  
> - return _dm_gpio_set_dir_flags(desc, desc->flags);
> + return _dm_gpio_update_flags(desc, desc->flags);
>  }
>  
>  int dm_gpio_get_dir_flags(struct gpio_desc *desc, ulong *flags)
> @@ -1307,8 +1307,8 @@ static int gpio_post_bind(struct udevice *dev)
>   ops->get_function += gd->reloc_off;
>   if (ops->xlate)
>   ops->xlate += gd->reloc_off;
> - if (ops->set_dir_flags)
> - ops->set_dir_flags += gd->reloc_off;
> + if (ops->update_flags)
> + ops->update_flags += gd->reloc_off;
>   if (ops->get_dir_flags)
>   ops->get_dir_flags += gd->reloc_off;
>  
> diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
> index dc8d506e8d4..029908dc9f9 100644
> --- a/drivers/gpio/sandbox.c
> +++ b/drivers/gpio/sandbox.c
> @@ -177,8 +177,8 @@ static int sb_gpio_xlate(struct udevice *dev, struct 
> gpio_desc *desc,
>   return 0;
>  }
>  
> -static int sb_gpio_set_dir_flags(struct udevice *dev, unsigned int offset,
> -  ulong flags)
> +static int sb_gpio_update_flags(struct udevice *dev, unsigned int offset,
> + ulong flags)
>  {
>   ulong *dir_flags;
>  
> @@ -272,7 +272,7 @@ static const struct dm_gpio_ops gpio_sandbox_ops = {
>   .set_value  = sb_gpio_set_value,
>   .get_function   = sb_gpio_get_function,
>   .xlate  = sb_gpio_xlate,
> - .set_dir_flags  = sb_gpio_set_dir_flags,
> + .update_flags   = sb_gpio_update_flags,
>   .get_dir_flags  = sb_gpio_get_dir_flags,
>  #if CONFIG_IS_ENABLED(ACPIGEN)
>   .get_acpi   = sb_gpio_get_acpi,
> diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
> index 79d55e812db..daae6ddb93f 100644
> --- a/drivers/gpio/stm32_gpio.c
> +++ b/drivers/gpio/stm32_gpio.c
> @@ -189,8 +189,8 @@ static int stm32_gpio_get_function(struct udevice *dev, 
> unsigned int offset)
>   return GPIOF_FUNC;
>  }
>  
> -static int stm32_gpio_set_dir_flags(struct udevice *dev, unsigned int offset,
> - ulong flags)
> +static int stm32_gpio_update_flags(struct udevice *dev, unsigned int offset,
> +ulong flags)
>  {
>   struct stm32_gpio_priv *priv = dev_get_priv(dev);
>   struct stm32_gpio_regs *regs = priv->regs;
> @@ -268,7 +268,7 @@ static const struct dm_gpio_ops gpio_stm32_ops = {
>   .get_value  = stm32_gpio_get_value,
>   

[PATCH 2/2] spi: nxp_fspi: Enable support for nxp,imx8mm-fspi

2021-01-18 Thread Adam Ford
The i.MX8M Mini can use the FlexSPI driver.  Add support
for it to the driver.

Signed-off-by: Adam Ford 

diff --git a/drivers/spi/nxp_fspi.c b/drivers/spi/nxp_fspi.c
index d74561578a..6c5bad4c2c 100644
--- a/drivers/spi/nxp_fspi.c
+++ b/drivers/spi/nxp_fspi.c
@@ -320,6 +320,14 @@ static const struct nxp_fspi_devtype_data lx2160a_data = {
.little_endian = true,  /* little-endian*/
 };
 
+static const struct nxp_fspi_devtype_data imx8mm_data = {
+   .rxfifo = SZ_512,   /* (64  * 64 bits)  */
+   .txfifo = SZ_1K,/* (128 * 64 bits)  */
+   .ahb_buf_size = SZ_2K,  /* (256 * 64 bits)  */
+   .quirks = 0,
+   .little_endian = true,  /* little-endian*/
+};
+
 struct nxp_fspi {
struct udevice *dev;
void __iomem *iobase;
@@ -985,6 +993,7 @@ static const struct dm_spi_ops nxp_fspi_ops = {
 
 static const struct udevice_id nxp_fspi_ids[] = {
{ .compatible = "nxp,lx2160a-fspi", .data = (ulong)_data, },
+   { .compatible = "nxp,imx8mm-fspi", .data = (ulong)_data, },
{ }
 };
 
-- 
2.25.1



[PATCH 1/2] spi: nxp_fspi: Fix error reporting

2021-01-18 Thread Adam Ford
On the i.MX8M Mini, ret = clk_set_rate() sets ret to the value of the
rate the clock was able to set.  When checking for errors, it only
checks that it is not NULL.  Since positive numbers are not errors,
only check for negative numbers when handling errors.

Fixes: 383fded70c4f ("spi: nxp_fspi: new driver for the FlexSPI controller")
Signed-off-by: Adam Ford 

diff --git a/drivers/spi/nxp_fspi.c b/drivers/spi/nxp_fspi.c
index 006dd04b9e..d74561578a 100644
--- a/drivers/spi/nxp_fspi.c
+++ b/drivers/spi/nxp_fspi.c
@@ -815,7 +815,7 @@ static int nxp_fspi_default_setup(struct nxp_fspi *f)
 
/* the default frequency, we will change it later if necessary. */
ret = clk_set_rate(>clk, 2000);
-   if (ret)
+   if (ret < 0)
return ret;
 
ret = nxp_fspi_clk_prep_enable(f);
@@ -906,7 +906,7 @@ static int nxp_fspi_set_speed(struct udevice *bus, uint 
speed)
nxp_fspi_clk_disable_unprep(f);
 
ret = clk_set_rate(>clk, speed);
-   if (ret)
+   if (ret < 0)
return ret;
 
ret = nxp_fspi_clk_prep_enable(f);
-- 
2.25.1



[PATCH] configs: am335x_evm: enable CONFIG_SPL_ALLOC_BD

2021-01-18 Thread Dario Binacchi
With commit 38d6b7ebdaee ("spl: Drop bd_info in the data section") you
need to enable this option to boot from mmc.

Signed-off-by: Dario Binacchi 
---

 configs/am335x_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index eb5a299bbc..c4d3bd0c44 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -13,6 +13,7 @@ CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run 
update_to_fit; fi; run f
 CONFIG_LOGLEVEL=3
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_ARCH_MISC_INIT=y
+CONFIG_SPL_ALLOC_BD=y
 CONFIG_SPL_FIT_IMAGE_TINY=y
 CONFIG_SPL_ETH_SUPPORT=y
 # CONFIG_SPL_FS_EXT4 is not set
-- 
2.17.1



Re: [PATCH 01/15] gpio: Disable functions not used with of-platdata

2021-01-18 Thread Pratyush Yadav
On 15/01/21 07:04AM, Simon Glass wrote:
> These functions use devicetree and cannot wprl with of-platdata, which has

Your right hand's offset is off by one ;-)

> no runtime devicetree.
> 
> If they are used, the current linker error is confusing, since it talks
> about missing functions in the bowels of driver model.
> 
> Avoid compiling these functions at all with of-platdata, so that a
> straightforward link error points to the problem.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/gpio/gpio-uclass.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index bad6b71e0c3..e84b68db772 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -1023,6 +1023,7 @@ err:
>   return ret;
>  }
>  
> +#if !CONFIG_IS_ENABLED(OF_PLATDATA)
>  static int _gpio_request_by_name_nodev(ofnode node, const char *list_name,
>  int index, struct gpio_desc *desc,
>  int flags, bool add_index)
> @@ -1109,6 +1110,7 @@ int gpio_get_list_count(struct udevice *dev, const char 
> *list_name)
>  
>   return ret;
>  }
> +#endif /* OF_PLATDATA */
>  
>  int dm_gpio_free(struct udevice *dev, struct gpio_desc *desc)
>  {
> -- 
> 2.30.0.284.gd98b1dd5eaa7-goog
> 

-- 
Regards,
Pratyush Yadav
Texas Instruments India


[PATCH 1/1] doc: move README.menu to HTML documentation

2021-01-18 Thread Heinrich Schuchardt
Convert README.menu to reStructured text and add it to the HTML
documentation.

Signed-off-by: Heinrich Schuchardt 
---
 doc/README.menu   | 124 ---
 doc/develop/index.rst |   1 +
 doc/develop/menus.rst | 131 ++
 3 files changed, 132 insertions(+), 124 deletions(-)
 delete mode 100644 doc/README.menu
 create mode 100644 doc/develop/menus.rst

diff --git a/doc/README.menu b/doc/README.menu
deleted file mode 100644
index 0f3d741605..00
--- a/doc/README.menu
+++ /dev/null
@@ -1,124 +0,0 @@
-SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright 2010-2011 Calxeda, Inc.
- */
-
-U-Boot provides a set of interfaces for creating and using simple, text
-based menus. Menus are displayed as lists of labeled entries on the
-console, and an entry can be selected by entering its label.
-
-To use the menu code, enable CONFIG_MENU, and include "menu.h" where
-the interfaces should be available.
-
-Menus are composed of items. Each item has a key used to identify it in
-the menu, and an opaque pointer to data controlled by the consumer.
-
-If you want to show a menu, instead starting the shell, define
-CONFIG_AUTOBOOT_MENU_SHOW. You have to code the int menu_show(int bootdelay)
-function, which handle your menu. This function returns the remaining
-bootdelay.
-
-Interfaces
---
-#include "menu.h"
-
-/*
- * Consumers of the menu interfaces will use a struct menu * as the
- * handle for a menu. struct menu is only fully defined in menu.c,
- * preventing consumers of the menu interfaces from accessing its
- * contents directly.
- */
-struct menu;
-
-/*
- * NOTE: See comments in common/menu.c for more detailed documentation on
- * these interfaces.
- */
-
-/*
- * menu_create() - Creates a menu handle with default settings
- */
-struct menu *menu_create(char *title, int timeout, int prompt,
-   void (*item_data_print)(void *),
-   char *(*item_choice)(void *),
-   void *item_choice_data);
-
-/*
- * menu_item_add() - Adds or replaces a menu item
- */
-int menu_item_add(struct menu *m, char *item_key, void *item_data);
-
-/*
- * menu_default_set() - Sets the default choice for the menu
- */
-int menu_default_set(struct menu *m, char *item_key);
-
-/*
- * menu_default_choice() - Set *choice to point to the default item's data
- */
-int menu_default_choice(struct menu *m, void **choice);
-
-/*
- * menu_get_choice() - Returns the user's selected menu entry, or the
- * default if the menu is set to not prompt or the timeout expires.
- */
-int menu_get_choice(struct menu *m, void **choice);
-
-/*
- * menu_destroy() - frees the memory used by a menu and its items.
- */
-int menu_destroy(struct menu *m);
-
-/*
- * menu_display_statusline(struct menu *m);
- * shows a statusline for every menu_display call.
- */
-void menu_display_statusline(struct menu *m);
-
-Example Code
-
-This example creates a menu that always prompts, and allows the user
-to pick from a list of tools.  The item key and data are the same.
-
-#include "menu.h"
-
-char *tools[] = {
-   "Hammer",
-   "Screwdriver",
-   "Nail gun",
-   NULL
-};
-
-char *pick_a_tool(void)
-{
-   struct menu *m;
-   int i;
-   char *tool = NULL;
-
-   m = menu_create("Tools", 0, 1, NULL);
-
-   for(i = 0; tools[i]; i++) {
-   if (menu_item_add(m, tools[i], tools[i]) != 1) {
-   printf("failed to add item!");
-   menu_destroy(m);
-   return NULL;
-   }
-   }
-
-   if (menu_get_choice(m, (void **)) != 1)
-   printf("Problem picking tool!\n");
-
-   menu_destroy(m);
-
-   return tool;
-}
-
-void caller(void)
-{
-   char *tool = pick_a_tool();
-
-   if (tool) {
-   printf("picked a tool: %s\n", tool);
-   use_tool(tool);
-   }
-}
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 83eb1307ed..beaa64d8d9 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -12,6 +12,7 @@ Implementation
commands
global_data
logging
+   menus

 Debugging
 -
diff --git a/doc/develop/menus.rst b/doc/develop/menus.rst
new file mode 100644
index 00..dda8f963fb
--- /dev/null
+++ b/doc/develop/menus.rst
@@ -0,0 +1,131 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright 2010-2011 Calxeda, Inc.
+
+Menus
+=
+
+U-Boot provides a set of interfaces for creating and using simple, text
+based menus. Menus are displayed as lists of labeled entries on the
+console, and an entry can be selected by entering its label.
+
+To use the menu code, enable CONFIG_MENU, and include "menu.h" where
+the interfaces should be available.
+
+Menus are composed of items. Each item has a key used to identify it in
+the menu, and an opaque pointer to data controlled by the consumer.
+
+If you want to show a menu, instead 

RE: IMX8MM SD UHS support

2021-01-18 Thread ZHIZHIKIN Andrey
Hello Tim,

Sorry it took me quite some time to get this sorted out, but I believe I was 
able to identify an offending commit that is preventing the USDHC to switch to 
higher speed modes.

It is in fact b5874b552f ("mmc: fsl_esdhc_imx: add wait_dat0() support"), 
reverting it makes SD Card to properly report capabilities and switch to high 
speed modes.

Can you try to revert this on your end to see if the SD Card would start to 
operate in high speed mode?

I'm still investigating why this addition of wait_dat0() caused this, I believe 
this is due to the fact that the same wait is already performed while voltage 
switch to handle the errata, thus this addition wait might erroneously timeout.

++ Haibo Chen 

Haibo,

Can you please explain the purpose of adding wait_dat0() Introduced with commit 
b5874b552f? It is not clear from the commit message what was the purpose of 
adding it. Have you tested the USDHC switch to higher modes with this change?

> -Original Message-
> From: Tim Harvey 
> Sent: Wednesday, January 6, 2021 12:10 AM
> To: ZHIZHIKIN Andrey 
> Cc: Adam Ford ; Fabio Estevam ;
> Peng Fan ; u-boot ; Stefano Babic
> 
> Subject: Re: IMX8MM SD UHS support
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> On Wed, Dec 30, 2020 at 1:00 PM ZHIZHIKIN Andrey  geosystems.com> wrote:
> >
> > Hello Tim,
> >
> > > -Original Message-
> > > From: Tim Harvey 
> > > Sent: Wednesday, December 30, 2020 7:48 PM
> > > To: Adam Ford 
> > > Cc: Fabio Estevam ; ZHIZHIKIN Andrey
> > > ; Peng Fan
> > > ; u- boot ; Stefano Babic
> > > 
> > > Subject: Re: IMX8MM SD UHS support
> > >
> > >
> > > On Wed, Dec 30, 2020 at 10:22 AM Adam Ford  wrote:
> > > >
> > > > On Wed, Dec 30, 2020 at 11:50 AM Fabio Estevam
> > > > 
> > > wrote:
> > > > >
> > > > > Hi Tim,
> > > > >
> > > > > On Wed, Dec 30, 2020 at 1:54 PM Tim Harvey
> > > > > 
> > > wrote:
> > > > >
> > > > > > Andrey,
> > > > > >
> > > > > > I did mention that I am using the imx8mm-evk. When I saw that
> > > > > > my custom board was having issues with sd_get_capabilities() I
> > > > > > switched to the imx8mm-evk and confirmed my findings there.
> >
> > I've missed the part that you've tested the same behavior on i.MX8M Mini EVK
> in your original message, sorry for that.
> >
> > > > > >
> > > > > > I'm using master (ab865a8ee5c1) with imx8mm_evk_defconfig
> > > > > > running on an imx8mm-evk board configured via dip switches to
> > > > > > boot from eMMC. I have a SDR104 microSD which detects and
> > > > > > operates as such in Linux and this is what I see in U-Boot:
> > > > > >
> > > > > > U-Boot SPL 2021.01-rc4-00029-gab865a8 (Dec 30 2020 - 08:29:24
> > > > > > -0800) Normal Boot
> > > > > > WDT:   Started with servicing (60s timeout)
> > > > > > Trying to boot from MMC2
> > > > > >
> > > > > >
> > > > > > U-Boot 2021.01-rc4-00029-gab865a8 (Dec 30 2020 - 08:29:24
> > > > > > -0800)
> > > > > >
> > > > > > CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> > > > > > Reset cause: POR
> > > > > > Model: FSL i.MX8MM EVK board
> > > > > > DRAM:  2 GiB
> > > > > > WDT:   Started with servicing (60s timeout)
> > > > > > MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> > > > > > Loading Environment from MMC... OK
> > > > > > In:serial
> > > > > > Out:   serial
> > > > > > Err:   serial
> > > > > > Net:   eth0: ethernet@30be
> > > > > > Hit any key to stop autoboot:  0 u-boot=> mmc dev 1 Run CMD11
> > > > > > 1.8V switch switch to partitions #0, OK
> > > > > > mmc1 is current device
> > > > > > u-boot=> mmc info
> > > > > > Device: FSL_SDHC
> > > > > > Manufacturer ID: 1b
> > > > > > OEM: 534d
> > > > > > Name: 0
> > > > > > Bus Speed: 5000
> > > > > > Mode: SD High Speed (50MHz)
> > > > > > Rd Block Len: 512
> > > > > > SD version 3.0
> > > > > > High Capacity: Yes
> > > > > > Capacity: 14.9 GiB
> > > > > > Bus Width: 4-bit
> > > > > > Erase Group Size: 512 Bytes
> > > > > >
> > > > > > You can see that the 1.8V switch succeeds and the card is
> > > > > > recognized as high-speed but does not show the SDR104 capability.
> >
> > Did you actually measured that the signaling voltages are switched to
> > 1v8 on the test point I've mentioned in my mail?
> >
> > > > >
> > > > > Could you please test this patch from Adam?
> > > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > 2Fpatchwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F2020123017390
> > > > > 7.2891555-1-
> aford173%40gmail.com%2Fdata=04%7C01%7C%7C12ecf6
> > > > >
> da5d4d4b8ea07708d8b1cf01ee%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C
> > > > >
> 0%7C0%7C637454849942704702%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> L
> > > > >
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> > > > >
> ;sdata=libCAoYJAg%2Brm2V%2BkrFBK%2FovUaWV0u1kbwHhj7pfues%3D
> > > > > reserved=0
> > > >
> >
> > If voltages are not actually switched - then probably another patch
> > from Adam might 

Re: [PATCH] spi: zynqmp_gqspi: support dual and quad mode

2021-01-18 Thread Brandon Maier
On Mon, Jan 18, 2021 at 2:17 AM Michal Simek  wrote:
>
> +Ashok

fyi I pushed up a working branch to github[1] where I've cherry-picked
commits from Xilinx/xlnx-u-boot for the zynqmp_gqspi.c, and resolved a
couple conflicts. In addition it has a fix for the dual-parallel mode
needed to work with exec_op()[2]

[1] https://github.com/bmaier-col/u-boot/tree/v2021.01-gqspi-public
[2] 
https://github.com/bmaier-col/u-boot/commit/0c50602816a5d0cadd8a010962c829f10bcc2f8c

>
> On 1/15/21 10:30 PM, Brandon Maier wrote:
> > The dm_spi_ops.xfer() API does not support dual and quad SPI modes. It
> > also doesn't allow the zynqmp_gqspi driver to calculate the correct
> > number of dummy cycles for some NOR ops (as doing so also requires the
> > buswidth).
> >
> > Port the zynqmp_gqspi driver to spi_controller_mem_ops, which gives us
> > the buswidth values to correctly support all SNOR_PROTO_X_X_X commands
> > and to properly calculate dummy cycles.
> >
> > Signed-off-by: Brandon Maier 
> > CC: ja...@amarulasolutions.com
> > CC: michal.si...@xilinx.com
> > ---
> >  drivers/spi/zynqmp_gqspi.c | 164 -
> >  1 file changed, 70 insertions(+), 94 deletions(-)
> >
> > diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
> > index efcbd0557f..e1fd551f68 100644
> > --- a/drivers/spi/zynqmp_gqspi.c
> > +++ b/drivers/spi/zynqmp_gqspi.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -171,8 +172,7 @@ struct zynqmp_qspi_priv {
> >   unsigned int len;
> >   int bytes_to_transfer;
> >   int bytes_to_receive;
> > - unsigned int is_inst;
> > - unsigned int cs_change:1;
> > + const struct spi_mem_op *op;
> >  };
> >
> >  static int zynqmp_qspi_of_to_plat(struct udevice *bus)
> > @@ -221,6 +221,21 @@ static u32 zynqmp_qspi_bus_select(struct 
> > zynqmp_qspi_priv *priv)
> >   return gqspi_fifo_reg;
> >  }
> >
> > +static u32 zynqmp_qspi_genfifo_mode(u8 buswidth)
> > +{
> > + switch (buswidth) {
> > + case 1:
> > + return GQSPI_SPI_MODE_SPI;
> > + case 2:
> > + return GQSPI_SPI_MODE_DUAL_SPI;
> > + case 4:
> > + return GQSPI_SPI_MODE_QSPI;
> > + default:
> > + debug("Unsupported bus width %u\n", buswidth);
> > + return GQSPI_SPI_MODE_SPI;
> > + }
> > +}
> > +
> >  static void zynqmp_qspi_fill_gen_fifo(struct zynqmp_qspi_priv *priv,
> > u32 gqspi_fifo_reg)
> >  {
> > @@ -445,21 +460,42 @@ static int zynqmp_qspi_fill_tx_fifo(struct 
> > zynqmp_qspi_priv *priv, u32 size)
> >
> >  static void zynqmp_qspi_genfifo_cmd(struct zynqmp_qspi_priv *priv)
> >  {
> > + const struct spi_mem_op *op = priv->op;
> >   u32 gen_fifo_cmd;
> > - u32 bytecount = 0;
> > + u8 i, dummy_cycles, addr;
> > +
> > + /* Send opcode */
> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
> > + gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(op->cmd.buswidth);
> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
> > + gen_fifo_cmd |= op->cmd.opcode;
> > + zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
> > +
> > + /* Send address */
> > + for (i = 0; i < op->addr.nbytes; i++) {
> > + addr = op->addr.val >> (8 * (op->addr.nbytes - i - 1));
> >
> > - while (priv->len) {
> >   gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
> > - gen_fifo_cmd |= GQSPI_GFIFO_TX | GQSPI_SPI_MODE_SPI;
> > - gen_fifo_cmd |= *(u8 *)priv->tx_buf;
> > - bytecount++;
> > - priv->len--;
> > - priv->tx_buf = (u8 *)priv->tx_buf + 1;
> > + gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(op->addr.buswidth);
> > + gen_fifo_cmd |= GQSPI_GFIFO_TX;
> > + gen_fifo_cmd |= addr;
> >
> >   debug("GFIFO_CMD_Cmd = 0x%x\n", gen_fifo_cmd);
> >
> >   zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
> >   }
> > +
> > + /* Send dummy */
> > + if (op->dummy.nbytes) {
> > + dummy_cycles = op->dummy.nbytes * 8 / op->dummy.buswidth;
> > +
> > + gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
> > + gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(op->dummy.buswidth);
> > + gen_fifo_cmd &= ~(GQSPI_GFIFO_TX | GQSPI_GFIFO_RX);
> > + gen_fifo_cmd |= GQSPI_GFIFO_DATA_XFR_MASK;
> > + gen_fifo_cmd |= dummy_cycles;
> > + zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);
> > + }
> >  }
> >
> >  static u32 zynqmp_qspi_calc_exp(struct zynqmp_qspi_priv *priv,
> > @@ -496,11 +532,10 @@ static int zynqmp_qspi_genfifo_fill_tx(struct 
> > zynqmp_qspi_priv *priv)
> >   int ret = 0;
> >
> >   gen_fifo_cmd = zynqmp_qspi_bus_select(priv);
> > + gen_fifo_cmd |= zynqmp_qspi_genfifo_mode(priv->op->data.buswidth);
> >   gen_fifo_cmd |= GQSPI_GFIFO_TX |
> >   GQSPI_GFIFO_DATA_XFR_MASK;
> >
> 

[PATCH 3/3] doc: move test/py/README.md to HTML documentation

2021-01-18 Thread Heinrich Schuchardt
Convert test/py/README.md to restructured text and add it to the generated
HTML documentation.

Signed-off-by: Heinrich Schuchardt 
---
 doc/develop/index.rst  |   1 +
 doc/develop/py_testing.rst | 426 +
 test/py/README.md  | 389 -
 3 files changed, 427 insertions(+), 389 deletions(-)
 create mode 100644 doc/develop/py_testing.rst
 delete mode 100644 test/py/README.md

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index ed2e73bf56..83eb1307ed 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -30,3 +30,4 @@ Testing

coccinelle
testing
+   py_testing
diff --git a/doc/develop/py_testing.rst b/doc/develop/py_testing.rst
new file mode 100644
index 00..f71e837aa9
--- /dev/null
+++ b/doc/develop/py_testing.rst
@@ -0,0 +1,426 @@
+U-Boot pytest suite
+===
+
+Introduction
+
+
+This tool aims to test U-Boot by executing U-Boot shell commands using the
+console interface. A single top-level script exists to execute or attach to the
+U-Boot console, run the entire script of tests against it, and summarize the
+results. Advantages of this approach are:
+
+- Testing is performed in the same way a user or script would interact with
+  U-Boot; there can be no disconnect.
+- There is no need to write or embed test-related code into U-Boot itself.
+  It is asserted that writing test-related code in Python is simpler and more
+  flexible than writing it all in C.
+- It is reasonably simple to interact with U-Boot in this way.
+
+Requirements
+
+
+The test suite is implemented using pytest. Interaction with the U-Boot console
+involves executing some binary and interacting with its stdin/stdout. You will
+need to implement various "hook" scripts that are called by the test suite at
+the appropriate time.
+
+In order to run the test suite at a minimum we require that both Python 3 and
+pip for Python 3 are installed. All of the required python modules are
+described in the requirements.txt file in the /test/py/ directory and can be
+installed via the command
+
+.. code-block:: bash
+
+   pip install -r requirements.txt
+
+In order to execute certain tests on their supported platforms other tools
+will be required. The following is an incomplete list:
+
+* gdisk
+* dfu-util
+* dtc
+* openssl
+* sudo OR guestmount
+* e2fsprogs
+* util-linux
+* coreutils
+* dosfstools
+* efitools
+* mount
+* mtools
+* sbsigntool
+* udisks2
+
+Please use the appropriate commands for your distribution to match these tools
+up with the package that provides them.
+
+The test script supports either:
+
+- Executing a sandbox port of U-Boot on the local machine as a sub-process,
+  and interacting with it over stdin/stdout.
+- Executing an external "hook" scripts to flash a U-Boot binary onto a
+  physical board, attach to the board's console stream, and reset the board.
+  Further details are described later.
+
+Using `virtualenv` to provide requirements
+~~
+
+The recommended way to run the test suite, in order to ensure reproducibility
+is to use `virtualenv` to set up the necessary environment.  This can be done
+via the following commands:
+
+
+.. code-block:: console
+
+$ cd /path/to/u-boot
+$ sudo apt-get install python3 python3-virtualenv
+$ virtualenv -p /usr/bin/python3 venv
+$ . ./venv/bin/activate
+$ pip install -r test/py/requirements.txt
+
+Testing sandbox
+---
+
+To run the test suite on the sandbox port (U-Boot built as a native user-space
+application), simply execute:
+
+.. code-block:: bash
+
+./test/py/test.py --bd sandbox --build
+
+The `--bd` option tells the test suite which board type is being tested. This
+lets the test suite know which features the board has, and hence exactly what
+can be tested.
+
+The `--build` option tells U-Boot to compile U-Boot. Alternatively, you may
+omit this option and build U-Boot yourself, in whatever way you choose, before
+running the test script.
+
+The test script will attach to U-Boot, execute all valid tests for the board,
+then print a summary of the test process. A complete log of the test session
+will be written to `${build_dir}/test-log.html`. This is best viewed in a web
+browser, but may be read directly as plain text, perhaps with the aid of the
+`html2text` utility.
+
+Testing under a debugger
+
+
+If you need to run sandbox under a debugger, you may pass the command-line
+option `--gdbserver COMM`. This causes two things to happens:
+
+- Instead of running U-Boot directly, it will be run under gdbserver, with
+  debug communication via the channel `COMM`. You can attach a debugger to the
+  sandbox process in order to debug it. See `man gdbserver` and the example
+  below for details of valid values for `COMM`.
+- All timeouts in tests are disabled, allowing U-Boot an arbitrary amount of
+  time to execute commands. This 

[PATCH 2/3] doc: move test/README to HTML documentation

2021-01-18 Thread Heinrich Schuchardt
Move test/README to the 'Develop U-Boot' chapter of the HTML documentation.

Signed-off-by: Heinrich Schuchardt 
---
 doc/develop/index.rst   |  1 +
 doc/develop/testing.rst | 96 +
 test/README | 96 -
 3 files changed, 97 insertions(+), 96 deletions(-)
 create mode 100644 doc/develop/testing.rst
 delete mode 100644 test/README

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index b108df8e1b..ed2e73bf56 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -29,3 +29,4 @@ Testing
:maxdepth: 1

coccinelle
+   testing
diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst
new file mode 100644
index 00..4bc9ca3a6a
--- /dev/null
+++ b/doc/develop/testing.rst
@@ -0,0 +1,96 @@
+Testing in U-Boot
+=
+
+U-Boot has a large amount of code. This file describes how this code is
+tested and what tests you should write when adding a new feature.
+
+
+Running tests
+-
+
+To run most tests on sandbox, type this:
+
+make check
+
+in the U-Boot directory. Note that only the pytest suite is run using this
+command.
+
+Some tests take ages to run. To run just the quick ones, type this:
+
+make qcheck
+
+
+Sandbox
+---
+U-Boot can be built as a user-space application (e.g. for Linux). This
+allows test to be executed without needing target hardware. The 'sandbox'
+target provides this feature and it is widely used in tests.
+
+
+Pytest Suite
+
+
+Many tests are available using the pytest suite, in test/py. This can run
+either on sandbox or on real hardware. It relies on the U-Boot console to
+inject test commands and check the result. It is slower to run than C code,
+but provides the ability to unify lots of tests and summarise their results.
+
+You can run the tests on sandbox with:
+
+   ./test/py/test.py --bd sandbox --build
+
+This will produce HTML output in build-sandbox/test-log.html
+
+See test/py/README.md for more information about the pytest suite.
+
+
+tbot
+
+
+Tbot provides a way to execute tests on target hardware. It is intended for
+trying out both U-Boot and Linux (and potentially other software) on a
+number of boards automatically. It can be used to create a continuous test
+environment. See http://www.tbot.tools for more information.
+
+
+Ad-hoc tests
+
+
+There are several ad-hoc tests which run outside the pytest environment:
+
+   test/fs - File system test (shell script)
+   test/image  - FIT and legacy image tests (shell script and Python)
+   test/stdint - A test that stdint.h can be used in U-Boot (shell script)
+   trace   - Test for the tracing feature (shell script)
+
+TODO: Move these into pytest.
+
+
+When to write tests
+---
+
+If you add code to U-Boot without a test you are taking a risk. Even if you
+perform thorough manual testing at the time of submission, it may break when
+future changes are made to U-Boot. It may even break when applied to mainline,
+if other changes interact with it. A good mindset is that untested code
+probably doesn't work and should be deleted.
+
+You can assume that the Pytest suite will be run before patches are accepted
+to mainline, so this provides protection against future breakage.
+
+On the other hand there is quite a bit of code that is not covered with tests,
+or is covered sparingly. So here are some suggestions:
+
+- If you are adding a new uclass, add a sandbox driver and a test that uses it
+- If you are modifying code covered by an existing test, add a new test case
+  to cover your changes
+- If the code you are modifying has not tests, consider writing one. Even a
+  very basic test is useful, and may be picked up and enhanced by others. It
+  is much easier to add onto a test - writing a new large test can seem
+  daunting to most contributors.
+
+
+Future work
+---
+
+Converting existing shell scripts into pytest tests.
diff --git a/test/README b/test/README
deleted file mode 100644
index 4bc9ca3a6a..00
--- a/test/README
+++ /dev/null
@@ -1,96 +0,0 @@
-Testing in U-Boot
-=
-
-U-Boot has a large amount of code. This file describes how this code is
-tested and what tests you should write when adding a new feature.
-
-
-Running tests
--
-
-To run most tests on sandbox, type this:
-
-make check
-
-in the U-Boot directory. Note that only the pytest suite is run using this
-command.
-
-Some tests take ages to run. To run just the quick ones, type this:
-
-make qcheck
-
-
-Sandbox

-U-Boot can be built as a user-space application (e.g. for Linux). This
-allows test to be executed without needing target hardware. The 'sandbox'
-target provides this feature and it is widely used in tests.
-
-
-Pytest Suite
-
-
-Many tests are available using the pytest suite, in test/py. This can run
-either on sandbox or on real hardware. It relies on the U-Boot 

[PATCH 1/3] doc: structure doc/develop/index.rst

2021-01-18 Thread Heinrich Schuchardt
Provide sub-chapters for 'Develop U-Boot'

Signed-off-by: Heinrich Schuchardt 
---
 doc/develop/index.rst | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 0a7e204b34..b108df8e1b 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -3,13 +3,29 @@
 Develop U-Boot
 ==

+Implementation
+--

 .. toctree::
-   :maxdepth: 2
+   :maxdepth: 1

-   coccinelle
commands
-   crash_dumps
global_data
logging
+
+Debugging
+-
+
+.. toctree::
+   :maxdepth: 1
+
+   crash_dumps
trace
+
+Testing
+---
+
+.. toctree::
+   :maxdepth: 1
+
+   coccinelle
--
2.29.2



[PATCH 0/3] move test related documentation to HTML

2021-01-18 Thread Heinrich Schuchardt
Restructure doc/develop/index.rst and move test related READMEs to the
generated HTML documentation.

Heinrich Schuchardt (3):
  doc: structure doc/develop/index.rst
  doc: move test/README to HTML documentation
  doc: move test/py/README.md to HTML documentation

 doc/develop/index.rst  |  24 ++-
 doc/develop/py_testing.rst | 426 +
 doc/develop/testing.rst|  96 +
 test/README|  96 -
 test/py/README.md  | 389 -
 5 files changed, 543 insertions(+), 488 deletions(-)
 create mode 100644 doc/develop/py_testing.rst
 create mode 100644 doc/develop/testing.rst
 delete mode 100644 test/README
 delete mode 100644 test/py/README.md

--
2.29.2



Re: [PULL] u-boot-sh/master

2021-01-18 Thread Tom Rini
On Mon, Jan 18, 2021 at 03:05:16PM +0100, Marek Vasut wrote:

> The following changes since commit 14ea1b3635b4af8d9e283e3671f7ee872d50b859:
> 
>   Merge branch '2021-01-15-assorted-improvements' (2021-01-16 11:14:21
> -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to 67704d6dfba5dcb3c33b0eb91e10f908c3dbbdcd:
> 
>   ARM: dts: renesas: Remove leading 0x from rpc node (2021-01-18 13:29:12
> +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request: u-boot-riscv/master

2021-01-18 Thread Tom Rini
On Mon, Jan 18, 2021 at 02:55:46PM +0800, ub...@andestech.com wrote:

> Hi Tom,
> 
> Please pull some riscv updates:
> 
> - Update qemu-riscv.rst build instructions.
> - Add support for SPI on Kendryte K210.
> - Add Microchip PolarFire SoC Icicle Kit support.
> - Add support for an early timer.
>  - select TIMER_EARLY to avoid infinite recursion for Trace.
> 
> Thanks
> Rick
> 
> CI: passed
> https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/5918
> 
> The following changes since commit 14ea1b3635b4af8d9e283e3671f7ee872d50b859:
> 
>   Merge branch '2021-01-15-assorted-improvements' (2021-01-16 11:14:21 -0500)
> 
> are available in the Git repository at:
> 
>   g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git
> 
> for you to fetch changes up to 9e550e18305fb31af83bfb72d16e86d8c054fb65:
> 
>   doc: board: Add Microchip MPFS Icicle Kit doc (2021-01-18 11:06:39 +0800)
> 

Applied to u-boot/master, thanks!


-- 
Tom


signature.asc
Description: PGP signature


Re: Pull request for documentation tag doc-2021-04-rc1

2021-01-18 Thread Tom Rini
On Sat, Jan 16, 2021 at 07:03:28PM +0100, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit b0db69b4e1e1bf1109bd9d4a5185cbd4058f4a8b:
> 
>   dm: fix build errors generated by last merges (2021-01-15 13:12:38 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/doc-2021-04-rc1
> 
> for you to fetch changes up to dd9abfec13884df0d9d30a6f79ffe80eeed9ac8c:
> 
>   doc: sifive: fu540: fix heading levels (2021-01-16 11:17:20 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/7] s5p4418_nanopi2: Bring in some dead code

2021-01-18 Thread Stefan Bosch

Hi Simon,

thanks a lot for your patch. I have just applied and tested it with the 
NanoPC-T2 board (is similar to the NanoPi2-board and therefore 
s5p4418_nanopi2_defconfig can be used). Unfortunately the bootl-cmd is 
not working out of the box:

  nanopi2# bootl
  FDT and ATAGS support not compiled in - hanging
  ### ERROR ### Please RESET the board ###

Therefore my suggestion is to remove cmd_boot_linux.c since the 
bootl-cmd is not required (friendlyARM's LUbuntu is booted by the 
bootz-cmd).


Regards
Stefan


On 16.01.21 22:54, Simon Glass wrote:

This code is still using the old command typedef. It was not noticed since
this file is not currently built. It is using a non-existent option in the
Makefile.

Fix it up and add it to the build.

(This is offered as an act of service in the hope of receiving a free
beer at some point.)

Signed-off-by: Simon Glass 
---

  arch/arm/mach-nexell/Makefile |  2 +-
  arch/arm/mach-nexell/cmd_boot_linux.c | 14 --
  2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-nexell/Makefile b/arch/arm/mach-nexell/Makefile
index 10b3963ed10..8113624cac3 100644
--- a/arch/arm/mach-nexell/Makefile
+++ b/arch/arm/mach-nexell/Makefile
@@ -10,4 +10,4 @@ obj-y += nx_gpio.o
  obj-y += tieoff.o
  obj-$(CONFIG_ARCH_S5P4418)+= reg-call.o
  obj-$(CONFIG_ARCH_S5P4418)+= nx_sec_reg.o
-obj-$(CONFIG_CMD_BOOTL)+= cmd_boot_linux.o
+obj-y  += cmd_boot_linux.o
diff --git a/arch/arm/mach-nexell/cmd_boot_linux.c 
b/arch/arm/mach-nexell/cmd_boot_linux.c
index f2dedfe1625..730550cd389 100644
--- a/arch/arm/mach-nexell/cmd_boot_linux.c
+++ b/arch/arm/mach-nexell/cmd_boot_linux.c
@@ -5,11 +5,13 @@
   */
  
  #include 

+#include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
+#include 
  #include 
  
  #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_CLI_FRAMEWORK)

@@ -18,7 +20,7 @@ DECLARE_GLOBAL_DATA_PTR;
  
  static bootm_headers_t linux_images;
  
-static void boot_go_set_os(cmd_tbl_t *cmdtp, int flag, int argc,

+static void boot_go_set_os(struct cmd_tbl *cmdtp, int flag, int argc,
   char * const argv[],
   bootm_headers_t *images)
  {
@@ -66,8 +68,8 @@ static void boot_start_lmb(bootm_headers_t *images)
  
  	lmb_init(>lmb);
  
-	mem_start = getenv_bootm_low();

-   mem_size = getenv_bootm_size();
+   mem_start = env_get_bootm_low();
+   mem_size = env_get_bootm_size();
  
  	lmb_add(>lmb, (phys_addr_t)mem_start, mem_size);
  
@@ -79,7 +81,7 @@ static void boot_start_lmb(bootm_headers_t *images)

  static inline void boot_start_lmb(bootm_headers_t *images) { }
  #endif
  
-int do_boot_linux(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

+int do_boot_linux(struct cmd_tbl *cmdtp, int flag, int argc, char * const 
argv[])
  {
boot_os_fn *boot_fn;
bootm_headers_t *images = _images;
@@ -126,7 +128,7 @@ U_BOOT_CMD(bootl, CONFIG_SYS_MAXARGS, 1, do_boot_linux,
  #endif
  
  #if defined(CONFIG_CMD_BOOTD) && !defined(CONFIG_CMD_BOOTM)

-int do_bootd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+int do_bootd(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[])
  {
return run_command(env_get("bootcmd"), flag);
  }



Re: [PATCH v3 1/8] spl: fit: Drop 'length' argument to board_spl_fit_post_load()

2021-01-18 Thread Tom Rini
On Mon, Jan 18, 2021 at 10:28:45AM -0600, Alex G. wrote:
> On 1/15/21 8:33 PM, Tom Rini wrote:
> > On Wed, Dec 23, 2020 at 08:44:05AM -0600, Alexandru Gagniuc wrote:
> > 
> > > The size is derived from the FIT image itself. Any alignment
> > > requirements are machine-specific and known by the board code. Thus
> > > the total length can be derived from the FIT image and knowledge of
> > > the platform. The 'length' argument is redundant. Remove it.
> > > 
> > > Signed-off-by: Alexandru Gagniuc 
> > > Reviewed-by: Peng Fan 
> > > Reviewed-by: Simon Glass 
> > > ---
> > >   arch/arm/mach-imx/spl.c | 5 +++--
> > >   common/spl/spl_fit.c| 4 ++--
> > >   include/spl.h   | 4 ++--
> > >   3 files changed, 7 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
> > > index aa2686bb92..11255798d3 100644
> > > --- a/arch/arm/mach-imx/spl.c
> > > +++ b/arch/arm/mach-imx/spl.c
> > > @@ -18,6 +18,7 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > +#include 
> > >   DECLARE_GLOBAL_DATA_PTR;
> > > @@ -318,9 +319,9 @@ ulong board_spl_fit_size_align(ulong size)
> > >   return size;
> > >   }
> > > -void board_spl_fit_post_load(ulong load_addr, size_t length)
> > > +void board_spl_fit_post_load(const void *fit)
> > >   {
> > > - u32 offset = length - CONFIG_CSF_SIZE;
> > > + u32 offset = ALIGN(fdt_totalsize(fit), 0x1000);
> > >   if (imx_hab_authenticate_image(load_addr,
> > >  offset + IVT_SIZE + CSF_PAD_SIZE,
> > 
> > OK, this is a problem right here.  First, the code no longer compiles as
> > we don't pass in "load_addr", which is what
> > imx_hab_authenticate_image() takes to know where in DDR the image is to
> > validate.  While I could probably work out that value from what we use
> > now for offset, I would rather someone that can test the code do so.
> > Thanks!
> > 
> 
> Hi Tom,
> 
> I'm sorry I missed that. I seemed to have, again, solved the hard problem
> and choked on something simple. Being able to eliminate the 'length'
> argument is essential simplifying the FIT code, and the rest of this series.
> Fixing the compilation issue is trivial, but how do we get this tested? Do
> you know someone with the hardware who'd be willing to give it a shot?

Actually, yes.  Please cc Matt Porter on the next re-spin and he can run
a boot test on fused hardware.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 1/8] spl: fit: Drop 'length' argument to board_spl_fit_post_load()

2021-01-18 Thread Alex G.

On 1/15/21 8:33 PM, Tom Rini wrote:

On Wed, Dec 23, 2020 at 08:44:05AM -0600, Alexandru Gagniuc wrote:


The size is derived from the FIT image itself. Any alignment
requirements are machine-specific and known by the board code. Thus
the total length can be derived from the FIT image and knowledge of
the platform. The 'length' argument is redundant. Remove it.

Signed-off-by: Alexandru Gagniuc 
Reviewed-by: Peng Fan 
Reviewed-by: Simon Glass 
---
  arch/arm/mach-imx/spl.c | 5 +++--
  common/spl/spl_fit.c| 4 ++--
  include/spl.h   | 4 ++--
  3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index aa2686bb92..11255798d3 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 
  
  DECLARE_GLOBAL_DATA_PTR;
  
@@ -318,9 +319,9 @@ ulong board_spl_fit_size_align(ulong size)

return size;
  }
  
-void board_spl_fit_post_load(ulong load_addr, size_t length)

+void board_spl_fit_post_load(const void *fit)
  {
-   u32 offset = length - CONFIG_CSF_SIZE;
+   u32 offset = ALIGN(fdt_totalsize(fit), 0x1000);
  
  	if (imx_hab_authenticate_image(load_addr,

   offset + IVT_SIZE + CSF_PAD_SIZE,


OK, this is a problem right here.  First, the code no longer compiles as
we don't pass in "load_addr", which is what
imx_hab_authenticate_image() takes to know where in DDR the image is to
validate.  While I could probably work out that value from what we use
now for offset, I would rather someone that can test the code do so.
Thanks!



Hi Tom,

I'm sorry I missed that. I seemed to have, again, solved the hard 
problem and choked on something simple. Being able to eliminate the 
'length' argument is essential simplifying the FIT code, and the rest of 
this series. Fixing the compilation issue is trivial, but how do we get 
this tested? Do you know someone with the hardware who'd be willing to 
give it a shot?


Alex


Re: [PATCH v4] cmd: Add a pwm command

2021-01-18 Thread Tom Rini
On Sun, Jan 17, 2021 at 05:35:17PM +0530, Pragnesh Patel wrote:
> Hi Tom,
> 
> Any comment on this ?

I'll likely be picking this up soon, thanks for your patience.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/2] efi_loader: make the UEFI boot manager configurable

2021-01-18 Thread Tom Rini
On Fri, Jan 15, 2021 at 09:31:19PM +0100, Heinrich Schuchardt wrote:
> On 1/15/21 7:43 PM, Tom Rini wrote:
> > On Fri, Jan 15, 2021 at 07:02:50PM +0100, Heinrich Schuchardt wrote:
> > 
> > > Some boards are very tight on the binary size. Booting via UEFI is 
> > > possible
> > > without using the boot manager.
> > 
> > While I don't think we need to re-word this part, for the record my
> > concern is global, not specific platforms.  To re-iterate something we
> > talked about on IRC, I think it's important to be able to select and
> > have a default UEFI implementation that covers as many common use cases
> > as possible, while also being as small as possible.
> > 
> > > 
> > > Provide a configuration option to make the boot manager available.
> > > 
> > > Signed-off-by: Heinrich Schuchardt 
> > [snip]
> > > +config CMD_BOOTEFI_BOOTMGR
> > > + bool "UEFI Boot Manager"
> > > + default y
> > > + help
> > > +   Select this option if you want to select the UEFI binary to be booted
> > > +   via UEFI variables Boot, BootOrder, and BootNext. This enables the
> > > +   'bootefi bootmgr' command.
> > 
> > I'm not sure this should be default y.  My concern is that the default
> > set of options is growing so that every possible case has support in the
> > binary but the hardware and practical use means we don't need all of
> > that.  This should perhaps be "default y if DISTRO_DEFAULTS" at least.
> 
> If you want to default something to no, I think that
> EFI_UNICODE_CAPITALIZATION is a better candidate.
> 
> On wandboard_defconfig:
> 
> 683976 - 680228 = 3748 bytes saved.

OK, thanks.  Can you make up a patch with sufficient explanation of why
it's OK to not support this by default?

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/3] test: missing build dependency for test_print.c

2021-01-18 Thread Heinrich Schuchardt
On 18.01.21 00:17, Heinrich Schuchardt wrote:
> test_print.c requires CONFIG_CONSOLE_RECORD=y.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  test/lib/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/test/lib/Makefile b/test/lib/Makefile
> index 98a9abf40e..97c11e35a8 100644
> --- a/test/lib/Makefile
> +++ b/test/lib/Makefile
> @@ -7,7 +7,7 @@ obj-$(CONFIG_EFI_LOADER) += efi_device_path.o
>  obj-$(CONFIG_EFI_SECURE_BOOT) += efi_image_region.o
>  obj-y += hexdump.o
>  obj-y += lmb.o
> -obj-y += test_print.o
> +obj-$(CONFIG_CONSOLE_RECORD) += test_print.o
>  obj-$(CONFIG_SSCANF) += sscanf.o
>  obj-y += string.o
>  obj-$(CONFIG_ERRNO_STR) += test_errno_str.o
> --
> 2.29.2
>
af033ec8b4ebe ("test: test/lib/test_print.c depends on CONSOLE_RECORD")
was merged today fixing the issue.

Best regards

Heinrich


Re: [PATCH 4/5] log: convert pr_*() to logging

2021-01-18 Thread Tom Rini
On Mon, Jan 18, 2021 at 08:02:41AM -0500, Tom Rini wrote:
> On Sun, Jan 17, 2021 at 08:37:15AM +0100, Heinrich Schuchardt wrote:
> > On 1/17/21 1:16 AM, Tom Rini wrote:
> > > On Mon, Jan 04, 2021 at 08:02:55AM +0100, Heinrich Schuchardt wrote:
> > > 
> > > > In drivers we use a family of printing functions including pr_err() and
> > > > pr_cont(). CONFIG_LOGLEVEL is used to control which of these lead to 
> > > > output
> > > > via printf().
> > > > 
> > > > Our logging functions allow finer grained control of output. So replace
> > > > printf() by the matching logging functions. The usage of CONFIG_LOGLEVEL
> > > > remains unchanged.
> > > > 
> > > > Signed-off-by: Heinrich Schuchardt 
> > > > ---
> > > >   include/linux/bitops.h |  4 ++-
> > > >   include/linux/printk.h | 82 +++---
> > > >   2 files changed, 48 insertions(+), 38 deletions(-)
> > > 
> > > This causes some fairly massive growth in various subsystems such as ubi
> > > and we might want to look at what, if anything, we can do, before
> > > growing some platforms by 15KiB (xilinx_zynqmp_virt) due to strings.
> > 
> > xilinx_zynqmp_virt has CONFIG_LOG enabled. Switching from printf() to
> > log() incurs size growth. Did you observe a size grows on platforms with
> > CONFIG_LOG=n?
> 
> Yes, it has logging enabled, and we're converting a large number of
> things that were before compile-time discarded to no longer be so.  This
> is, in general, good and what I've asked for.  But when seeing very
> large growth in doing so, I think we need to maybe take a step back and
> look at the UBI subsystem for example and see if we can't/shouldn't
> tweak things more.
> 
> So, I'm going to run a size test with just this patch as the change, so
> we can have more concrete numbers to look at.

OK, so the build is done and interesting output starts at:
https://gist.github.com/trini/53e7da62c6c9d18c189e6baffd01ff00#file-2021-01-18-0800-txt-L239

Most of the time we're well under 1KiB, which is great.  UBI has some
huge growth, but it's a very few platforms, and I've added the
custodians here so they can object, or not, to such size growth.

-- 
Tom


signature.asc
Description: PGP signature


Re: Invitation: Regular U-Boot video call (Tuesday 19th)

2021-01-18 Thread Marek Vasut

On 1/14/21 6:42 AM, Bin Meng wrote:

Hi Simon,

On Thu, Jan 14, 2021 at 5:57 AM Simon Glass  wrote:


Hi Bin,

I added you, Heinrich, Tom and Andy.

For others, as mentioned in the doc I can add you to the invitation.
Just reply on this thread.



I am not sure how Google meet works as I never used that. I guess Zoom
is much easier as it has clients on different platforms.


What about jitsi meet ? meet.jit.si seems to be an option ?


[PULL] u-boot-sh/master

2021-01-18 Thread Marek Vasut

The following changes since commit 14ea1b3635b4af8d9e283e3671f7ee872d50b859:

  Merge branch '2021-01-15-assorted-improvements' (2021-01-16 11:14:21 
-0500)


are available in the Git repository at:

  git://git.denx.de/u-boot-sh.git master

for you to fetch changes up to 67704d6dfba5dcb3c33b0eb91e10f908c3dbbdcd:

  ARM: dts: renesas: Remove leading 0x from rpc node (2021-01-18 
13:29:12 +0100)



Lad Prabhakar (3):
  pinctrl: renesas: Make sure the pin type is updated after setting 
the MUX

  pinctrl: renesas: Implement get_pin_muxing() callback
  ARM: dts: renesas: Remove leading 0x from rpc node

 arch/arm/dts/r7s72100-gr-peach-u-boot.dts |  2 +-
 arch/arm/dts/r8a77950-u-boot.dtsi |  2 +-
 arch/arm/dts/r8a77960-u-boot.dtsi |  2 +-
 arch/arm/dts/r8a77965-u-boot.dtsi |  2 +-
 arch/arm/dts/r8a77970-u-boot.dtsi |  2 +-
 arch/arm/dts/r8a77980-u-boot.dtsi |  2 +-
 arch/arm/dts/r8a77990-u-boot.dtsi |  2 +-
 arch/arm/dts/r8a77995-u-boot.dtsi |  2 +-
 drivers/pinctrl/renesas/pfc.c | 77 
-

 9 files changed, 80 insertions(+), 13 deletions(-)



Re: [PATCH] arm64: a37xx: pci: Fix printing debug messages

2021-01-18 Thread Stefan Roese

On 18.01.21 12:09, Pali Rohár wrote:

Value pcie->dev in function pcie_advk_probe() is not initialized yet
so use dev as argument for dev_dbg()/dev_warn().

Function pcie_advk_wait_pio() itself prints error message on failure
so do not print duplicate error message in caller.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/pci/pci-aardvark.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 1534efb88e..8713b88461 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -448,7 +448,6 @@ static int pcie_advk_write_config(struct udevice *bus, 
pci_dev_t bdf,
advk_writel(pcie, 1, PIO_START);
  
  	if (!pcie_advk_wait_pio(pcie)) {

-   dev_dbg(pcie->dev, "- wait pio timeout\n");
return -EINVAL;
}
  
@@ -630,12 +629,12 @@ static int pcie_advk_probe(struct udevice *dev)

 * clock should be gated as well.
 */
if (dm_gpio_is_valid(>reset_gpio)) {
-   dev_dbg(pcie->dev, "Toggle PCIE Reset GPIO ...\n");
+   dev_dbg(dev, "Toggle PCIE Reset GPIO ...\n");
dm_gpio_set_value(>reset_gpio, 1);
mdelay(200);
dm_gpio_set_value(>reset_gpio, 0);
} else {
-   dev_warn(pcie->dev, "PCIE Reset on GPIO support is missing\n");
+   dev_warn(dev, "PCIE Reset on GPIO support is missing\n");
}
  
  	pcie->first_busno = dev_seq(dev);





Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH v2] usb: xhci-pci: Check for errors from dm_pci_map_bar()

2021-01-18 Thread Stefan Roese

On 18.01.21 12:30, Pali Rohár wrote:

Function dm_pci_map_bar() may fail and returns NULL. Check this to prevent
dereferencing a NULL pointer.

In xhci-pci this may happen when board does not enable CONFIG_PCI_PNP and
PCI_BASE_ADDRESS_0 contains unconfigured zero address.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


Re: [PATCH] usb: xhci-pci: Check for errors from dm_pci_map_bar()

2021-01-18 Thread Stefan Roese

On 18.01.21 12:13, Pali Rohár wrote:

Function dm_pci_map_bar() may fail and returns NULL. Check this to prevent
dereferencing a NULL pointer.

In xhci-pci this may happen when board does not enable CONFIG_PCI_PNP and
PCI_BASE_ADDRESS_0 contains unconfigured zero address.

Signed-off-by: Pali Rohár 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/usb/host/xhci-pci.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 2b445f21b5..7f5be95f6c 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -13,7 +13,7 @@
  #include 
  #include 
  
-static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,

+static int xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
  struct xhci_hcor **ret_hcor)
  {
struct xhci_hccr *hccr;
@@ -22,6 +22,11 @@ static void xhci_pci_init(struct udevice *dev, struct 
xhci_hccr **ret_hccr,
  
  	hccr = (struct xhci_hccr *)dm_pci_map_bar(dev,

PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
+   if (!hccr) {
+   printf("XHCI-PCI init cannot map PCI mem bar\n");
+   return -EIO;
+   }
+
hcor = (struct xhci_hcor *)((uintptr_t) hccr +
HC_LENGTH(xhci_readl(>cr_capbase)));
  
@@ -35,14 +40,18 @@ static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,

dm_pci_read_config32(dev, PCI_COMMAND, );
cmd |= PCI_COMMAND_MASTER;
dm_pci_write_config32(dev, PCI_COMMAND, cmd);
+   return 0;
  }
  
  static int xhci_pci_probe(struct udevice *dev)

  {
struct xhci_hccr *hccr;
struct xhci_hcor *hcor;
+   int ret;
  
-	xhci_pci_init(dev, , );

+   ret = xhci_pci_init(dev, , );
+   if (ret)
+   return ret;
  
  	return xhci_register(dev, hccr, hcor);

  }




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH] cmd: disk: Remove fit_print_contents API

2021-01-18 Thread Tom Rini
On Fri, Jan 08, 2021 at 09:55:58AM -0800, Ravik Hasija wrote:

> fit_print_contents prints similar fit information as printed in bootm stages.
> Removing this API reduces redundancy & provides improvement in boottime.
> 
> Signed-off-by: Ravik Hasija 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] lib: cosmetic update of CONFIG_LIB_ELF description

2021-01-18 Thread Tom Rini
On Mon, Jan 04, 2021 at 03:33:28PM +0100, Patrick Delaunay wrote:

> Change 2 typo error in CONFIG_LIB_ELF description:
> - Supoort => Support
> - fir => for
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 5/5] test: unit test for pr_err(), pr_cont()

2021-01-18 Thread Tom Rini
On Mon, Jan 04, 2021 at 08:02:56AM +0100, Heinrich Schuchardt wrote:

> Provide a unit test for printing via pr_err() and pr_cont().
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 4/5] log: convert pr_*() to logging

2021-01-18 Thread Tom Rini
On Sun, Jan 17, 2021 at 08:37:15AM +0100, Heinrich Schuchardt wrote:
> On 1/17/21 1:16 AM, Tom Rini wrote:
> > On Mon, Jan 04, 2021 at 08:02:55AM +0100, Heinrich Schuchardt wrote:
> > 
> > > In drivers we use a family of printing functions including pr_err() and
> > > pr_cont(). CONFIG_LOGLEVEL is used to control which of these lead to 
> > > output
> > > via printf().
> > > 
> > > Our logging functions allow finer grained control of output. So replace
> > > printf() by the matching logging functions. The usage of CONFIG_LOGLEVEL
> > > remains unchanged.
> > > 
> > > Signed-off-by: Heinrich Schuchardt 
> > > ---
> > >   include/linux/bitops.h |  4 ++-
> > >   include/linux/printk.h | 82 +++---
> > >   2 files changed, 48 insertions(+), 38 deletions(-)
> > 
> > This causes some fairly massive growth in various subsystems such as ubi
> > and we might want to look at what, if anything, we can do, before
> > growing some platforms by 15KiB (xilinx_zynqmp_virt) due to strings.
> 
> xilinx_zynqmp_virt has CONFIG_LOG enabled. Switching from printf() to
> log() incurs size growth. Did you observe a size grows on platforms with
> CONFIG_LOG=n?

Yes, it has logging enabled, and we're converting a large number of
things that were before compile-time discarded to no longer be so.  This
is, in general, good and what I've asked for.  But when seeing very
large growth in doing so, I think we need to maybe take a step back and
look at the UBI subsystem for example and see if we can't/shouldn't
tweak things more.

So, I'm going to run a size test with just this patch as the change, so
we can have more concrete numbers to look at.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/5] log: provide missing macros

2021-01-18 Thread Tom Rini
On Mon, Jan 04, 2021 at 08:02:54AM +0100, Heinrich Schuchardt wrote:

> With commit d094a0734cee ("log: allow for message continuation") we have
> defined a special log level and category for message continuation. Let's
> have a macro for using these.
> 
> If logging is enabled log_cont() will create a continuation log output with
> the same logging level and category as the previous message.
> 
> If logging is not enabled, log_cont() will print like printf().
> 
> Provide macros for logging levels LOG_EMERG, LOG_ALERT, LOG_CRIT.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/5] log: make debug_cond() function like

2021-01-18 Thread Tom Rini
On Mon, Jan 04, 2021 at 08:02:53AM +0100, Heinrich Schuchardt wrote:

> Change debug_cond() such that it can be used instead of a function like
> debug().
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/5] ram: k3-j721e: rename BIT_MASK()

2021-01-18 Thread Tom Rini
On Mon, Jan 04, 2021 at 08:02:52AM +0100, Heinrich Schuchardt wrote:

> The macro BIT_MASK is already defined in include/linux/bitops.h. To avoid
> name collisions rename BIT_MASK() in drivers/ram/k3-j721e/lpddr4_private.h
> to LPDDR4_BIT_MASK().
> 
> Remove superfluous parantheses.
> Remove superfluous comparison to 0.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] mtd: misplaced log.h and dm/devres.h

2021-01-18 Thread Tom Rini
On Sun, Jan 03, 2021 at 04:10:45PM +0100, Heinrich Schuchardt wrote:

> log.h and dm/devres.h are U-Boot includes. So placing them
> behind #ifndef __UBOOT__ does not make any sense.
> 
> Fixes: f7ae49fc4f36 ("common: Drop log.h from common header")
> Fixes: 61b29b826838 ("dm: core: Require users of devres to include the 
> header")
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] lib: zlib: our putc() takes only one argument

2021-01-18 Thread Tom Rini
On Mon, Dec 28, 2020 at 09:41:40PM +0100, Heinrich Schuchardt wrote:

> In contrast to the C99 standard [1] our putc() takes only one argument.
> 
> [1] ISO/IEC 9899:1999
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] lib: zlib: include ctype.h

2021-01-18 Thread Tom Rini
On Mon, Dec 28, 2020 at 09:31:43PM +0100, Heinrich Schuchardt wrote:

> Our ctype.h is in include/linux/
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] lib: aes: build failure with DEBUG=1

2021-01-18 Thread Tom Rini
On Mon, Dec 28, 2020 at 05:56:27PM +0100, Heinrich Schuchardt wrote:

> Building fails with DEBUG=1:
> 
> lib/aes.c: In function ‘debug_print_vector’:
> lib/aes.c:622:45: error:
> cast from pointer to integer of different size
> [-Werror=pointer-to-int-cast]
>   622 |  printf("%s [%d] @0x%08x", name, num_bytes, (u32)data);
> 
> Pointers can only be cast to (uintptr_t). But anyway we have
> %p for printing pointers.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/3] armv8: Makefile: build cache files when needed

2021-01-18 Thread Tom Rini
On Mon, Dec 28, 2020 at 08:13:13PM +0800, Peng Fan (OSS) wrote:

> From: Peng Fan 
> 
> If no need cache support, not build the cache files, such as in SPL.
> 
> Signed-off-by: Peng Fan 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/3] common: Makefile: drop duplicated line

2021-01-18 Thread Tom Rini
On Mon, Dec 28, 2020 at 08:13:11PM +0800, Peng Fan (OSS) wrote:

> From: Peng Fan 
> 
> obj-$(CONFIG_$(SPL_TPL_)YMODEM_SUPPORT) += xyzModem.o is there,
> no need obj-$(CONFIG_SPL_YMODEM_SUPPORT) += xyzModem.o
> 
> Signed-off-by: Peng Fan 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] dts: Log name of expected .dtb file

2021-01-18 Thread Tom Rini
On Sun, Dec 27, 2020 at 09:34:43PM +0100, Florian Klink wrote:

> Make it more obvious what .dts file was expected by the build system.
> 
> When adding support for a new board, I kept getting this error message,
> assuming I passed a wrong DEVICE_TREE parameter.
> 
> However, what was really the mistake was that the entry in
> `arch/arm/dts/Makefile` was missing, and u-boot didn't like not being
> able to find the .dtb file that should have been produced.
> 
> Simply logging the expected .dtb file name should make it easier to spot
> such mistakes.
> 
> Signed-off-by: Florian Klink 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] bootmenu: Allow to quit it via ESC/CTRL+C

2021-01-18 Thread Tom Rini
On Sun, Dec 27, 2020 at 01:04:38AM +0100, Pali Rohár wrote:

> When ESC/CTRL+C is pressed interrupt bootmenu and jump into U-Boot console.
> As the last entry in bootmenu is always U-Boot console just choose the last
> entry when ESC or CTRL+C is pressed.
> 
> ESC key is detected when either no other character appears after '\e'
> within 10ms or when non-'[' appears after '\e'.
> 
> It is useful when bootmenu is part of boot process and you want to
> interrupt boot process by scripts which control U-Boot (serial) console.
> 
> Signed-off-by: Pali Rohár 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] string: Use memcpy() within memmove() when we can

2021-01-18 Thread Tom Rini
On Fri, Dec 11, 2020 at 02:59:23PM +0100, Patrick Delaunay wrote:

> A common use of memmove() can be handled by memcpy(). Also memcpy()
> includes an optimization for large sizes: it copies a word at a time. So
> we can get a speed-up by calling memcpy() to handle our move in this case.
> 
> Update memmove() to call also memcpy() if the source don't overlap
> the destination (src + count <= dest).
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5 2/2] drivers: serial: probe all uart devices

2021-01-18 Thread Tom Rini
On Wed, Dec 09, 2020 at 10:42:04AM +0530, Vabhav Sharma wrote:

> From: Vabhav Sharma 
> 
> U-Boot DM model probe only single device at a time
> which is enabled and configured using device tree
> or platform data method.
> 
> PL011 UART IP is SBSA compliant and firmware does the
> serial port set-up, initialization and let the kernel use
> UART port for sending and receiving characters.
> 
> Normally software talk to one serial port time but some
> LayerScape platform require all the UART devices enabled
> in Linux for various use case.
> 
> Adding support to probe all enabled serial devices like SBSA
> compliant PL011 UART ports probe and initialization by firmware.
> 
> Signed-off-by: Vabhav Sharma 
> Reviewed-by: Stefan Roese 
> Reviewed-by: Simon Glass 
> Reviewed-by: Sean Anderson 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5 1/2] dm: core: add function uclass_probe_all() to probe all devices

2021-01-18 Thread Tom Rini
On Wed, Dec 09, 2020 at 10:42:03AM +0530, Vabhav Sharma wrote:

> From: Vabhav Sharma 
> 
> Support a common method to probe all devices associated with uclass.
> 
> This includes data structures and code for finding the first device and
> looping for remaining devices associated with uclasses (groups of devices
> with the same purpose, e.g. all SERIAL ports will be in the same uclass).
> 
> An example is SBSA compliant PL011 UART IP, where firmware does the serial
> port initialization and prepare uart device to let the kernel use it for
> sending and reveiving the characters.SERIAL uclass will use this function
> to initialize PL011 UART ports.
> 
> The feature is enabled with CONFIG_DM.
> 
> Signed-off-by: Vabhav Sharma 
> Reviewed-by: Stefan Roese 
> Reviewed-by: Simon Glass 
> Reviewed-by: Sean Anderson 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] console: cosmetics: remove #if 0

2021-01-18 Thread Tom Rini
On Wed, Dec 02, 2020 at 03:16:13PM +0100, Patrick Delaunay wrote:

> Remove the #if 0 present since the first version of console.c
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] common: always compile fixup_cmdtable()

2021-01-18 Thread Tom Rini
On Thu, Nov 26, 2020 at 08:46:37PM +0100, Heinrich Schuchardt wrote:

> With our optimization settings the linker eliminates unused functions.
> 
> But for debugging it is better to compile with -Og or -O0. With -O0
> compiling the sandbox fails due to the missing function fixup_cmdtable()
> called by dm_reloc() and others.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] common: spl: spl_fit.c: report an error on hash check fail

2021-01-18 Thread Tom Rini
On Tue, Nov 24, 2020 at 04:15:05PM +0100, Philippe Reynes wrote:

> When the hash check fails on a loadable image, the SPL/TPL simply
> jump to the next one. This commit changes this behaviour, when the
> hash check fails on a loadable image, the function spl_load_simple_fit
> stops and report an error.
> 
> Signed-off-by: Philippe Reynes 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] cli_readline: Only insert printable chars

2021-01-18 Thread Tom Rini
On Sun, Nov 22, 2020 at 02:58:45PM +1000, Steve Bennett wrote:

> There should be no need to insert non-printable characters
> and this prevents line editing getting confused.
> 
> Signed-off-by: Steve Bennett 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3] Add optional salt to AUTOBOOT_STOP_STR_SHA256

2021-01-18 Thread Tom Rini
On Sat, Nov 21, 2020 at 05:18:59PM -0800, Joel Peshkin wrote:

> Adds an optional SALT value to AUTOBOOT_STOP_STR_SHA256.   If a string
> followed by a ":" is prepended to the sha256, the portion to the left
> of the colon will be used as a salt and the password will be appended
> to the salt before the sha256 is computed and compared.
> 
> Signed-off-by: Joel Peshkin 
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Patrick Delaunay 
> Cc: Heiko Schocher 
> Cc: Heinrich Schuchardt 
> Cc: Joel Peshkin 
> To: u-boot@lists.denx.de
> Reviewed-by: Simon Glass 
> Reviewed-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/3] doc/README.gpt: reflow partition type GUID table

2021-01-18 Thread Tom Rini
On Fri, Nov 20, 2020 at 11:45:37AM +0100, Rasmus Villemoes wrote:

> The previous patch made the table look bad. Fix it, and leave some
> space for a future element being a bit longer than the current
> maximum.
> 
> Signed-off-by: Rasmus Villemoes 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/3] doc/README.gpt: define partition type GUID for U-Boot environment

2021-01-18 Thread Tom Rini
On Fri, Nov 20, 2020 at 11:45:36AM +0100, Rasmus Villemoes wrote:

> When setting aside a GPT partition for holding the U-Boot environment,
> having a partition type GUID [1] indicating "Linux filesystem" (as
> most tools default to) is somewhat misleading - and there's no other
> well-known type GUID that is better suited. So to have a canonical
> value to put into the type field, define
> 
> 3de21764-95bd-54bd-a5c3-4abe786f38a8
> 
> to mean a partition holding a U-Boot environment.
> 
> This is a v5 namespace-name GUID [2], generated [3] from a namespace
> of "25cbcde0-8642-47c6-a298-1a3a57cd256b" and name "U-Boot
> environment".
> 
> Should future type GUIDs be defined in the context of U-Boot, it's
> sensible to use that same namespace GUID.
> 
> [1] https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
> [2] 
> https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based)
> [3] https://www.uuidtools.com/v5
> 
> Signed-off-by: Rasmus Villemoes 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/3] lib/uuid.c: change prototype of uuid_guid_get_str()

2021-01-18 Thread Tom Rini
On Fri, Nov 20, 2020 at 11:45:35AM +0100, Rasmus Villemoes wrote:

> There's no reason to require an appropriately sized output parameter
> for the string, that's error-prone should the table ever grow an
> element with a longer string. We can just return the const char*
> pointer directly.
> 
> Update the only caller accordingly, and get rid of pointless ifdeffery
> in the header so that the compiler always sees a declaration and can
> thus do type-checking, whether or not PARTITION_TYPE_GUID is enabled
> or not.
> 
> Signed-off-by: Rasmus Villemoes 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] power: regulator: Kconfig: add a dependency for POWER_SUPPORT for SPL

2021-01-18 Thread Tom Rini
On Thu, Nov 19, 2020 at 10:10:54PM -0600, Nishanth Menon wrote:

> power/regulator will not be built if just CONFIG_SPL_DM_REGULATOR is
> enabled. It needs CONFIG_SPL_POWER_SUPPORT to be enabled as well.
> 
> For example, if we just need a GPIO regulator in SPL:
> CONFIG_DM_REGULATOR=y
> CONFIG_SPL_DM_REGULATOR=y
> CONFIG_DM_REGULATOR_GPIO=y
> CONFIG_SPL_DM_REGULATOR_GPIO=y
> 
> Will not suffice, since the entire regulator build for SPL depends on
> CONFIG_SPL_POWER_SUPPORT. Elaborate that information in the Kconfig
> dependency.
> 
> Signed-off-by: Nishanth Menon 
> Reviewed-by: Jaehoon Chung 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 3/3] test: correct the test prefix in ut str

2021-01-18 Thread Tom Rini
On Thu, Nov 19, 2020 at 10:08:43AM +0100, Patrick Delaunay wrote:

> Align the prefix used in cmd_ut_category function and name of tests
> for ut str.
> This patch solves the issues detected by "make qcheck" after previous
> patch.
> 
> Fixes: fdc79a6b125d ("lib: Add a function to convert a string to upper case")
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/3] test: correct the test prefix in ut cmd_mem

2021-01-18 Thread Tom Rini
On Thu, Nov 19, 2020 at 10:08:42AM +0100, Patrick Delaunay wrote:

> Align the prefix used in cmd_ut_category function and name of tests
> for ut mem.
> This patch solves the issues detected by "make qcheck" after previous
> patch.
> 
> Fixes: 550a9e7902ce ("cmd: Update the memory-search command")
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v5 1/1] cmd: gpt: add eMMC and GPT support

2021-01-18 Thread Tom Rini
On Mon, Nov 09, 2020 at 11:49:16AM +0530, Rayagonda Kokatanur wrote:

> From: Corneliu Doban 
> 
> Add eMMC and GPT support.
> - GPT partition list and command to create the GPT added to u-boot
>   environment
> - eMMC boot commands added to u-boot environment
> - new gpt commands (enumarate and setenv) that are used by broadcom
>   update scripts and boot commands
> - eMMC specific u-boot configurations with environment saved in eMMC
>   and GPT support
> 
> Signed-off-by: Corneliu Doban 
> Signed-off-by: Rayagonda Kokatanur 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] Kconfig: simple panel requires backlight

2021-01-18 Thread Tom Rini
On Thu, Nov 05, 2020 at 05:30:26PM +0100, Marcin Juszkiewicz wrote:

> During build of simple panel driver backlight is needed so let's enable
> it:
> 
> aarch64-linux-gnu-ld.bfd: drivers/built-in.o: in function 
> `simple_panel_set_backlight':
> u-boot/drivers/video/simple_panel.c:43: undefined reference to 
> `backlight_set_brightness'
> aarch64-linux-gnu-ld.bfd: drivers/built-in.o: in function 
> `simple_panel_enable_backlight':
> u-boot/drivers/video/simple_panel.c:28: undefined reference to 
> `backlight_enable'
> 
> Signed-off-by: Marcin Juszkiewicz 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] test: test/lib/test_print.c depends on CONSOLE_RECORD

2021-01-18 Thread Tom Rini
On Thu, Nov 05, 2020 at 01:29:06AM +0100, Heinrich Schuchardt wrote:

> The tests in test/lib/test_print.c fail without CONFIG_CONSOLE_RECORD=y.
> 
> Add a build dependency.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] cmd: CMD_CPU depends on CPU

2021-01-18 Thread Tom Rini
On Thu, Nov 05, 2020 at 12:29:11AM +0100, Heinrich Schuchardt wrote:

> Compiling with CONFIG_CMD_CPU=y and CONFIG_CPU=n fails with:
> 
> aarch64-linux-gnu-ld.bfd: cmd/built-in.o: in function `print_cpu_list':
> /home/user/u-boot/cmd/cpu.c:34: undefined reference to `cpu_get_desc'
> aarch64-linux-gnu-ld.bfd:
> /home/user/u-boot/cmd/cpu.c:39: undefined reference to `cpu_get_info'
> Segmentation fault (core dumped)
> make: *** [Makefile:1757: u-boot] Error 139
> make: *** Deleting file 'u-boot'
> 
> See error report in https://stackoverflow.com/questions/64678347.
> 
> Add the missing build dependency.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v4 0/3] VIM3: add support for checking 'Function' button state

2021-01-18 Thread Neil Armstrong
Hi,

On 18/01/2021 13:48, Heinrich Schuchardt wrote:
> On 18.01.21 11:24, Neil Armstrong wrote:
>> Hi,
>>
>> On 22/12/2020 09:56, Marek Szyprowski wrote:
>>> Hi All,
>>>
>>> This patchset adds all building blocks needed for checking the 'Function'
>>> button state in the boot script on Amlogic A311D based VIM3 board. This
>>> button is connected to the ADC lines of the SoC, so it required to enable
>>> meson SARADC, the clocks needed for it and a simple button-adc drivers.
>>>
>>> Once applied, one can use following commands in the boot scripts:
>>> -->8---
>>> echo Checking Func button state: \\c
>>> if button Function
>>> then
>>> echo Selected alternative boot
>>> ...
>>> fi
>>> --->8---
>>>
>>> Best regards
>>> Marek Szyprowski
>>> Samsung R Institute Poland
>>>
>>>
>>> Changelog:
>>> v4:
>>> - rebased onto uboot-amlogic/u-boot-amlogic-next and dropped merged patches
>>> - added adc-keys bindings docs (copied from Linux kernel)
>>> - minor code adjustments pointed by Simon
>>> - enabled driver also in khadas-vim3l_defconfig
>>>
>>> v3: https://lists.denx.de/pipermail/u-boot/2020-December/435072.html
>>> - removed 'button' env variable
>>> - extended kconfig and patch descriptions
>>>
>>> v2: https://lists.denx.de/pipermail/u-boot/2020-December/434991.html
>>> - removed Change-Id tags
>>> - split defconfig changes into ADC and button related
>>>
>>> v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html
>>> - initial submission
>>
>> What's the state of the patchset ?
> 
> Hello Neil,
> 
> the series is assigned to you. Patch 2 is incorrect. Patch 1 can be
> updated to match Linux. So I suggest to set the status for the series to
> "changes requested".
> 

Sure, it was more a question to Marek, but yeah I'll tag them "changes 
requested"

Neil

> Best regards
> 
> Heinrich
> 
>>
>> Neil
>>
>>>
>>>
>>> Patch summary:
>>>
>>> Marek Szyprowski (3):
>>>   dt-bindings: input: adc-keys bindings documentation
>>>   button: add a simple Analog to Digital Converter device based button
>>> driver
>>>   configs: khadas-vim3(l): enable Function button support
>>>
>>>  configs/khadas-vim3_defconfig   |   2 +
>>>  configs/khadas-vim3l_defconfig  |   2 +
>>>  doc/device-tree-bindings/input/adc-keys.txt |  49 
>>>  drivers/button/Kconfig  |   8 ++
>>>  drivers/button/Makefile |   1 +
>>>  drivers/button/button-adc.c | 121 
>>>  6 files changed, 183 insertions(+)
>>>  create mode 100644 doc/device-tree-bindings/input/adc-keys.txt
>>>  create mode 100644 drivers/button/button-adc.c
>>>
>>
> 



Re: [PATCH 0/2] efi_loader: make the UEFI boot manager configurable

2021-01-18 Thread Heinrich Schuchardt
On 18.01.21 03:33, AKASHI Takahiro wrote:
> Heinrich,
>
> On Fri, Jan 15, 2021 at 07:02:48PM +0100, Heinrich Schuchardt wrote:
>> Some boards are very tight on the binary size. Booting via UEFI is possible
>> without using the boot manager.
>>
>> Provide a configuration option to make the boot manager available.
>>
>> Heinrich Schuchardt (2):
>>   efi_loader: move load options to new module
>>   efi_loader: make the UEFI boot manager configurable
>>
>>  cmd/bootefi.c |  13 ++-
>>  cmd/efidebug.c|   8 +-
>>  lib/efi_loader/Kconfig|   8 ++
>>  lib/efi_loader/Makefile   |   3 +-
>>  lib/efi_loader/efi_bootmgr.c  | 135 --
>
> "efidebug" command also has some related code in that "Boot" variables
> are handled solely by boot manager.
> You can opt it out for the sake of consistency.

As we discussed with Ilias that part will be split off into a separate
command anyway. So this will be done in a later patch.

Best regards

Heinrich

>
> -Takahiro Akashi
>
>
>>  lib/efi_loader/efi_load_options.c | 151 ++
>>  6 files changed, 176 insertions(+), 142 deletions(-)
>>  create mode 100644 lib/efi_loader/efi_load_options.c
>>
>> --
>> 2.29.2
>>



Re: [PATCH v4 0/3] VIM3: add support for checking 'Function' button state

2021-01-18 Thread Heinrich Schuchardt
On 18.01.21 11:24, Neil Armstrong wrote:
> Hi,
>
> On 22/12/2020 09:56, Marek Szyprowski wrote:
>> Hi All,
>>
>> This patchset adds all building blocks needed for checking the 'Function'
>> button state in the boot script on Amlogic A311D based VIM3 board. This
>> button is connected to the ADC lines of the SoC, so it required to enable
>> meson SARADC, the clocks needed for it and a simple button-adc drivers.
>>
>> Once applied, one can use following commands in the boot scripts:
>> -->8---
>> echo Checking Func button state: \\c
>> if button Function
>> then
>>  echo Selected alternative boot
>>  ...
>> fi
>> --->8---
>>
>> Best regards
>> Marek Szyprowski
>> Samsung R Institute Poland
>>
>>
>> Changelog:
>> v4:
>> - rebased onto uboot-amlogic/u-boot-amlogic-next and dropped merged patches
>> - added adc-keys bindings docs (copied from Linux kernel)
>> - minor code adjustments pointed by Simon
>> - enabled driver also in khadas-vim3l_defconfig
>>
>> v3: https://lists.denx.de/pipermail/u-boot/2020-December/435072.html
>> - removed 'button' env variable
>> - extended kconfig and patch descriptions
>>
>> v2: https://lists.denx.de/pipermail/u-boot/2020-December/434991.html
>> - removed Change-Id tags
>> - split defconfig changes into ADC and button related
>>
>> v1: https://lists.denx.de/pipermail/u-boot/2020-December/434875.html
>> - initial submission
>
> What's the state of the patchset ?

Hello Neil,

the series is assigned to you. Patch 2 is incorrect. Patch 1 can be
updated to match Linux. So I suggest to set the status for the series to
"changes requested".

Best regards

Heinrich

>
> Neil
>
>>
>>
>> Patch summary:
>>
>> Marek Szyprowski (3):
>>   dt-bindings: input: adc-keys bindings documentation
>>   button: add a simple Analog to Digital Converter device based button
>> driver
>>   configs: khadas-vim3(l): enable Function button support
>>
>>  configs/khadas-vim3_defconfig   |   2 +
>>  configs/khadas-vim3l_defconfig  |   2 +
>>  doc/device-tree-bindings/input/adc-keys.txt |  49 
>>  drivers/button/Kconfig  |   8 ++
>>  drivers/button/Makefile |   1 +
>>  drivers/button/button-adc.c | 121 
>>  6 files changed, 183 insertions(+)
>>  create mode 100644 doc/device-tree-bindings/input/adc-keys.txt
>>  create mode 100644 drivers/button/button-adc.c
>>
>



Re: [PATCH v4 1/3] dt-bindings: input: adc-keys bindings documentation

2021-01-18 Thread Heinrich Schuchardt
On 22.12.20 12:28, Heinrich Schuchardt wrote:
> On 12/22/20 11:12 AM, Heinrich Schuchardt wrote:
>> On 12/22/20 9:56 AM, Marek Szyprowski wrote:
>>> Dump adc-keys bindings documentation from Linux kernel source tree
>>> v5.10.
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> ---
>>>   doc/device-tree-bindings/input/adc-keys.txt | 49 +
>>>   1 file changed, 49 insertions(+)
>>>   create mode 100644 doc/device-tree-bindings/input/adc-keys.txt
>>>
>>> diff --git a/doc/device-tree-bindings/input/adc-keys.txt
>>> b/doc/device-tree-bindings/input/adc-keys.txt
>>> new file mode 100644
>>> index 00..e551814629
>>> --- /dev/null
>>> +++ b/doc/device-tree-bindings/input/adc-keys.txt
>>> @@ -0,0 +1,49 @@
>>> +ADC attached resistor ladder buttons
>>> +
>>> +
>>> +Required properties:
>>> + - compatible: "adc-keys"
>>> + - io-channels: Phandle to an ADC channel
>>> + - io-channel-names = "buttons";
>>> + - keyup-threshold-microvolt: Voltage at which all the keys are
>>> considered up.
>>> +
>>> +Optional properties:
>>> +    - poll-interval: Poll interval time in milliseconds
>>> +    - autorepeat: Boolean, Enable auto repeat feature of Linux input
>>> +  subsystem.
>>> +
>>> +Each button (key) is represented as a sub-node of "adc-keys":
>>> +
>>> +Required subnode-properties:
>>> +    - label: Descriptive name of the key.
>>> +    - linux,code: Keycode to emit.
>>> +    - press-threshold-microvolt: Voltage ADC input when this key is
>>> pressed.
>>
>> https://www.merriam-webster.com/dictionary/threshold
>> defines threshold as "a level, point, or value above which something is
>> true or will take place and below which it is not or will not"
>>
>> "when this key is pressed" leaves it completely open if a key is
>> considered pressed below or above the threshold. Please, replace the
>> word 'when' by either 'above which' or 'below which'.
>>
>> In the example keyup-threshold-microvolt is larger than
>> keyup-threshold-microvolt all values of press-threshold-microvolt. So
>> one might assume that 'above' is the intended meaning and the
>> interpretation of the example might be:
>>
>> 2.000.000 <= value: no key pressed
>> 1.500.000 <= value < 2.000.000: KEY_VOLUMEUP pressed
>> 1.000.000 <= value < 1.500.000: KEY_VOLUMEDOWN pressed
>> 500.000 <= value < 1.000.000: KEY_ENTER pressed
>> value < 500.000: no key pressed
>>
>> Both directions 'above' and 'below' make sense. So maybe if
>> keyup-threshold-microvolt is lower than all press-threshold-microvolt
>> you want to invert the logic?
>>
>> The binding lacks a hysteresis which is needed for a reliable function.
>>
>> If you look into drivers/input/keyboard/adc-keys.c in the Linux source,
>> you can see that it is not using the threshold value as a threshold at
>> all. Instead is uses abs(st->map[i].voltage - value) to find the nearest
>> "threshold" voltage level.
>>
>> Could you, please, try to bring this text into a form that cannot be
>> misinterpreted and reconcile with upstream. This should include
>>
>> * a results table for the example
>> * a definition if keyup-threshold-microvolt must be higher than all
>>    press-threshold-microvolt or may be lower than all
>>    press-threshold-microvolt
>> * a sentence forbidding keyup-threshold-microvolt to be between two
>>    press-threshold-microvolt
>> * a definition if or when any of the thresholds is a lower or upper
>>    boundary
>
> Cf. [PATCH 1/1] dt-bindings: adc-keys.txt: clarify description
> https://lore.kernel.org/linux-input/20201222110815.24121-1-xypron.g...@gmx.de/T/#u

My patch has been accepted into Linux next.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20210118=698dc0cf944772a79a9aa417e647c0f7587e51df

Best regards

Heinrich

>>> +
>>> +Example:
>>> +
>>> +#include 
>>> +
>>> +    adc-keys {
>>> +    compatible = "adc-keys";
>>> +    io-channels = < 0>;
>>> +    io-channel-names = "buttons";
>>> +    keyup-threshold-microvolt = <200>;
>>> +
>>> +    button-up {
>>> +    label = "Volume Up";
>>> +    linux,code = ;
>>> +    press-threshold-microvolt = <150>;
>>> +    };
>>> +
>>> +    button-down {
>>> +    label = "Volume Down";
>>> +    linux,code = ;
>>> +    press-threshold-microvolt = <100>;
>>> +    };
>>> +
>>> +    button-enter {
>>> +    label = "Enter";
>>> +    linux,code = ;
>>> +    press-threshold-microvolt = <50>;
>>> +    };
>>> +    };
>>>
>>
>



Re: [PATCH 0/7] zynqmp_gqspi driver updates

2021-01-18 Thread Bin Meng
On Mon, Jan 18, 2021 at 8:35 PM Ashok Reddy Soma
 wrote:
>
> This patch series updates xilinx qspi driver with below fixes/enhancements
>
>  - Fix rounding off issue in DMA transfers
>  - Fix DMA transfers to be word aligned
>  - Add support for IO mode
>  - Fix write issues in QSPI single mode
>  - Fix zynqmp tapdelays
>  - Add Versal tapdelays
>  - Update tapdelay for >100Mhz for Versal
>
> This is resend for the people in CC, as i had trouble with my email
> server earlier.
>
>
>
> Ashok Reddy Soma (3):
>   spi: zynqmp_gqspi: Add support for IO mode
>   spi: zynqmp_gqspi: Fix write issues in single mode
>   spi: zynqmp_gqspi: Add tap delays for Versal qspi
>
> Siva Durga Prasad Paladugu (1):
>   spi: zynqmp_gqspi: Fix tap delay values
>
> T Karthik Reddy (1):
>   spi: zynqmp_gqspi: Update tapdelay value
>
> Wojciech Tatarski (2):
>   spi: zynqmp_gqspi: do not round immediate_data field
>   spi: zynqmp_gqspi: DMA transfers should be word aligned
>
>  drivers/spi/zynqmp_gqspi.c | 230 +
>  1 file changed, 180 insertions(+), 50 deletions(-)
>

+Brandon Maier


Re: [PATCH 1/2] spi: mtk_snor: add support for MTK SPI NOR controller

2021-01-18 Thread SkyLake Huang
On Tue, 2020-12-08 at 01:48 +0800, Jagan Teki wrote:
> On Fri, Nov 13, 2020 at 8:32 AM SkyLake Huang
>  wrote:
> >
> > From: "SkyLake.Huang" 
> >
> > This patch adds support for MTK SPI NOR controller, which you
> > can see on mt7622 & mt7629.
> >
> > This controller is designed only for SPI NOR. We can't adjust
> > its bus clock dynamically. Set clock in dts instead.
> >
> > Signed-off-by: SkyLake.Huang 
> > ---
> >  drivers/spi/Kconfig|   7 +
> >  drivers/spi/Makefile   |   1 +
> >  drivers/spi/mtk_snor.c | 597 +
> >  3 files changed, 605 insertions(+)
> >  create mode 100644 drivers/spi/mtk_snor.c
> >
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > index fae2040af8..670af450c1 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -174,6 +174,13 @@ config MT7621_SPI
> >   the SPI NOR flash on platforms embedding this Ralink / MediaTek
> >   SPI core, like MT7621/7628/7688.
> >
> > +config MTK_SNOR
> > +   bool "Mediatek SPI-NOR controller driver"
> > +   depends on SPI_MEM
> > +   help
> > + Enable the Mediatek SPINOR controller driver. This driver has
> > +  better read/write performance with NOR.
> > +
> >  config MTK_SNFI_SPI
> > bool "Mediatek SPI memory controller driver"
> > depends on SPI_MEM
> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> > index ae4f2958f8..efe92f6b18 100644
> > --- a/drivers/spi/Makefile
> > +++ b/drivers/spi/Makefile
> > @@ -38,6 +38,7 @@ obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o
> >  obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
> >  obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
> >  obj-$(CONFIG_MTK_SNFI_SPI) += mtk_snfi_spi.o
> > +obj-$(CONFIG_MTK_SNOR) += mtk_snor.o
> >  obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
> >  obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o
> >  obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
> > diff --git a/drivers/spi/mtk_snor.c b/drivers/spi/mtk_snor.c
> > new file mode 100644
> > index 00..0a92f1c5a8
> > --- /dev/null
> > +++ b/drivers/spi/mtk_snor.c
> > @@ -0,0 +1,597 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// Mediatek SPI-NOR controller driver
> > +//
> > +// Copyright (C) 2020 SkyLake Huang 
> > +//
> > +// Some parts are based on drivers/spi/spi-mtk-nor.c of linux version
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME "mtk-spi-nor"
> > +
> > +#define MTK_NOR_REG_CMD0x00
> > +#define MTK_NOR_CMD_WRSR   BIT(5)
> > +#define MTK_NOR_CMD_WRITE  BIT(4)
> > +#define MTK_NOR_CMD_PROGRAMBIT(2)
> > +#define MTK_NOR_CMD_RDSR   BIT(1)
> > +#define MTK_NOR_CMD_READ   BIT(0)
> > +#define MTK_NOR_CMD_MASK   GENMASK(5, 0)
> > +
> > +#define MTK_NOR_REG_PRG_CNT0x04
> > +#define MTK_NOR_REG_RDSR   0x08
> > +#define MTK_NOR_REG_RDATA  0x0c
> > +
> > +#define MTK_NOR_REG_RADR0  0x10
> > +#define MTK_NOR_REG_RADR(n)(MTK_NOR_REG_RADR0 + 4 * (n))
> > +#define MTK_NOR_REG_RADR3  0xc8
> > +
> > +#define MTK_NOR_REG_WDATA  0x1c
> > +
> > +#define MTK_NOR_REG_PRGDATA0   0x20
> > +#define MTK_NOR_REG_PRGDATA(n) (MTK_NOR_REG_PRGDATA0 + 4 * (n))
> > +#define MTK_NOR_REG_PRGDATA_MAX5
> > +
> > +#define MTK_NOR_REG_SHIFT0 0x38
> > +#define MTK_NOR_REG_SHIFT(n)   (MTK_NOR_REG_SHIFT0 + 4 * (n))
> > +#define MTK_NOR_REG_SHIFT_MAX  9
> > +
> > +#define MTK_NOR_REG_CFG1   0x60
> > +#define MTK_NOR_FAST_READ  BIT(0)
> > +
> > +#define MTK_NOR_REG_CFG2   0x64
> > +#define MTK_NOR_WR_CUSTOM_OP_ENBIT(4)
> > +#define MTK_NOR_WR_BUF_EN  BIT(0)
> > +
> > +#define MTK_NOR_REG_PP_DATA0x98
> > +
> > +#define MTK_NOR_REG_IRQ_STAT   0xa8
> > +#define MTK_NOR_REG_IRQ_EN 0xac
> > +#define MTK_NOR_IRQ_DMABIT(7)
> > +#define MTK_NOR_IRQ_WRSR   BIT(5)
> > +#define MTK_NOR_IRQ_MASK   GENMASK(7, 0)
> > +
> > +#define MTK_NOR_REG_CFG3   0xb4
> > +#define MTK_NOR_DISABLE_WREN   BIT(7)
> > +#define MTK_NOR_DISABLE_SR_POLLBIT(5)
> > +
> > +#define MTK_NOR_REG_WP 0xc4
> > +#define MTK_NOR_ENABLE_SF_CMD  0x30
> > +
> > +#define MTK_NOR_REG_BUSCFG 0xcc
> > +#define MTK_NOR_4B_ADDRBIT(4)
> > +#define MTK_NOR_QUAD_ADDR  BIT(3)
> > +#define MTK_NOR_QUAD_READ  BIT(2)
> > +#define MTK_NOR_DUAL_ADDR  BIT(1)
> > +#define MTK_NOR_DUAL_READ  BIT(0)
> > +#define MTK_NOR_BUS_MODE_MASK 

Minor update in U-boot - FIT image check signature tool

2021-01-18 Thread Ilies CHERGUI
Hey guys,

I hope you are doing well.
Happy new year.

I have a small patch to apply in u-boot concerning the tool for FIT image
check signature (please see the attached file).

Have a nice weekend.

Best regards

**

*M. Ilies CHERGUI*

*Senior Embedded Software Engineer *

*Mobile : *+44 7309 350477

*E-mail :* ilies.cher...@gmail.com

**
From fa84f03114a07ed204d793a3d0ca48064bb2f3dd Mon Sep 17 00:00:00 2001
From: Ilies CHERGUI 
Date: Sun, 17 Jan 2021 15:52:16 +
Subject: [PATCH] tools/fit_check_sign.c: Update usage function.

Add "-c" option to set the configuration name when
checking the FIT image signature.

Signed-off-by: Ilies CHERGUI 
---
 tools/fit_check_sign.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/fit_check_sign.c b/tools/fit_check_sign.c
index 9375d5cf72..5573842d25 100644
--- a/tools/fit_check_sign.c
+++ b/tools/fit_check_sign.c
@@ -25,9 +25,10 @@
 
 void usage(char *cmdname)
 {
-	fprintf(stderr, "Usage: %s -f fit file -k key file\n"
+	fprintf(stderr, "Usage: %s -f fit file -k key file -c config name\n"
 			 "  -f ==> set fit file which should be checked'\n"
-			 "  -k ==> set key file which contains the key'\n",
+			 "  -k ==> set key file which contains the key'\n"
+			 "  -c ==> set the configuration name'\n",
 		cmdname);
 	exit(EXIT_FAILURE);
 }
-- 
2.17.1



[PATCH 7/7] spi: zynqmp_gqspi: Update tapdelay value

2021-01-18 Thread Ashok Reddy Soma
From: T Karthik Reddy 

Update GQSPI_LPBK_DLY_ADJ_DLY_1 tapdelay value for Versal for
frequencies above 100MHz.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Ashok Reddy Soma 
---

 drivers/spi/zynqmp_gqspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index e9726912b7..0771541e12 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -92,7 +92,7 @@

 #define GQSPI_BAUD_DIV_SHIFT   2
 #define GQSPI_LPBK_DLY_ADJ_LPBK_SHIFT  5
-#define GQSPI_LPBK_DLY_ADJ_DLY_1   0x2
+#define GQSPI_LPBK_DLY_ADJ_DLY_1   0x1
 #define GQSPI_LPBK_DLY_ADJ_DLY_1_SHIFT 3
 #define GQSPI_LPBK_DLY_ADJ_DLY_0   0x3
 #define GQSPI_USE_DATA_DLY 0x1
--
2.17.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


[PATCH 6/7] spi: zynqmp_gqspi: Add tap delays for Versal qspi

2021-01-18 Thread Ashok Reddy Soma
This patch adds tap delays for qspi in Versal platform.
Use IS_ENABLED() to address for ZynqMP and Versal and re-align the
tapdelays code.

Signed-off-by: Ashok Reddy Soma 
---

 drivers/spi/zynqmp_gqspi.c | 54 ++
 1 file changed, 37 insertions(+), 17 deletions(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index f50a7304ea..e9726912b7 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -102,8 +102,10 @@
 #define TAP_DLY_BYPASS_LQSPI_RX_VALUE  0x1
 #define TAP_DLY_BYPASS_LQSPI_RX_SHIFT  2
 #define GQSPI_DATA_DLY_ADJ_OFST0x01F8
-#define IOU_TAPDLY_BYPASS_OFST 0xFF180390
+#define IOU_TAPDLY_BYPASS_OFST !IS_ENABLED(CONFIG_ARCH_VERSAL) ? \
+   0xFF180390 : 0xF103003C
 #define GQSPI_LPBK_DLY_ADJ_LPBK_MASK   0x0020
+#define GQSPI_FREQ_37_5MHZ 3750
 #define GQSPI_FREQ_40MHZ   4000
 #define GQSPI_FREQ_100MHZ  1
 #define GQSPI_FREQ_150MHZ  15000
@@ -296,23 +298,41 @@ void zynqmp_qspi_set_tapdelay(struct udevice *bus, u32 
baudrateval)
debug("%s, req_hz:%d, clk_rate:%d, baudrateval:%d\n",
  __func__, reqhz, clk_rate, baudrateval);

-   if (reqhz <= GQSPI_FREQ_40MHZ) {
-   tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
-   TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
-   } else if (reqhz <= GQSPI_FREQ_100MHZ) {
-   tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
-   TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
-   lpbkdlyadj = GQSPI_LPBK_DLY_ADJ_LPBK_MASK;
-   datadlyadj = (GQSPI_USE_DATA_DLY << GQSPI_USE_DATA_DLY_SHIFT) |
- (GQSPI_DATA_DLY_ADJ_VALUE <<
-  GQSPI_DATA_DLY_ADJ_SHIFT);
-   } else if (reqhz <= GQSPI_FREQ_150MHZ) {
-   lpbkdlyadj = GQSPI_LPBK_DLY_ADJ_LPBK_MASK |
- GQSPI_LPBK_DLY_ADJ_DLY_0;
+   if (!IS_ENABLED(CONFIG_ARCH_VERSAL)) {
+   if (reqhz <= GQSPI_FREQ_40MHZ) {
+   tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
+   TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
+   } else if (reqhz <= GQSPI_FREQ_100MHZ) {
+   tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
+   TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
+   lpbkdlyadj = GQSPI_LPBK_DLY_ADJ_LPBK_MASK;
+   datadlyadj = (GQSPI_USE_DATA_DLY <<
+ GQSPI_USE_DATA_DLY_SHIFT) |
+  (GQSPI_DATA_DLY_ADJ_VALUE <<
+   GQSPI_DATA_DLY_ADJ_SHIFT);
+   } else if (reqhz <= GQSPI_FREQ_150MHZ) {
+   lpbkdlyadj = GQSPI_LPBK_DLY_ADJ_LPBK_MASK |
+ GQSPI_LPBK_DLY_ADJ_DLY_0;
+   }
+   zynqmp_mmio_write(IOU_TAPDLY_BYPASS_OFST,
+ IOU_TAPDLY_BYPASS_MASK, tapdlybypass);
+   } else {
+   if (reqhz <= GQSPI_FREQ_37_5MHZ) {
+   tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
+   TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
+   } else if (reqhz <= GQSPI_FREQ_100MHZ) {
+   tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
+   TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
+   lpbkdlyadj = GQSPI_LPBK_DLY_ADJ_LPBK_MASK;
+   datadlyadj = GQSPI_USE_DATA_DLY <<
+ GQSPI_USE_DATA_DLY_SHIFT;
+   } else if (reqhz <= GQSPI_FREQ_150MHZ) {
+   lpbkdlyadj = GQSPI_LPBK_DLY_ADJ_LPBK_MASK |
+ (GQSPI_LPBK_DLY_ADJ_DLY_1 <<
+  GQSPI_LPBK_DLY_ADJ_DLY_1_SHIFT);
+   }
+   writel(tapdlybypass, IOU_TAPDLY_BYPASS_OFST);
}
-
-   zynqmp_mmio_write(IOU_TAPDLY_BYPASS_OFST, IOU_TAPDLY_BYPASS_MASK,
- tapdlybypass);
writel(lpbkdlyadj, >lpbkdly);
writel(datadlyadj, >gqspidlyadj);
 }
--
2.17.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


[PATCH 5/7] spi: zynqmp_gqspi: Fix write issues in single mode

2021-01-18 Thread Ashok Reddy Soma
Add dummy write to genfifo register in chipselect.

Enable manual start in zynqmp_qspi_fill_gen_fifo().

Also enable GQSPI_IXR_GFNFULL_MASK and check for it instead of
GQSPI_IXR_GFEMTY_MASK.

Signed-off-by: Ashok Reddy Soma 
---

 drivers/spi/zynqmp_gqspi.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index 136c20f09e..f50a7304ea 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -239,10 +239,21 @@ static void zynqmp_qspi_fill_gen_fifo(struct 
zynqmp_qspi_priv *priv,
  u32 gqspi_fifo_reg)
 {
struct zynqmp_qspi_regs *regs = priv->regs;
+   u32 config_reg, ier;
int ret = 0;

+   config_reg = readl(>confr);
+   /* Manual start if needed */
+   config_reg |= GQSPI_STRT_GEN_FIFO;
+   writel(config_reg, >confr);
+
+   /* Enable interrupts */
+   ier = readl(>ier);
+   ier |= GQSPI_IXR_GFNFULL_MASK;
+   writel(ier, >ier);
+
/* Wait until the fifo is not full to write the new command */
-   ret = wait_for_bit_le32(>isr, GQSPI_IXR_GFEMTY_MASK, 1,
+   ret = wait_for_bit_le32(>isr, GQSPI_IXR_GFNFULL_MASK, 1,
GQSPI_TIMEOUT, 1);
if (ret)
printf("%s Timeout\n", __func__);
@@ -265,6 +276,9 @@ static void zynqmp_qspi_chipselect(struct zynqmp_qspi_priv 
*priv, int is_on)

debug("GFIFO_CMD_CS: 0x%x\n", gqspi_fifo_reg);

+   /* Dummy generic FIFO entry */
+   zynqmp_qspi_fill_gen_fifo(priv, 0);
+
zynqmp_qspi_fill_gen_fifo(priv, gqspi_fifo_reg);
 }

--
2.17.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


[PATCH 4/7] spi: zynqmp_gqspi: Fix tap delay values

2021-01-18 Thread Ashok Reddy Soma
From: Siva Durga Prasad Paladugu 

There is no need of read modify write for tapdelay settings
ans hence remove the read operations while setting tapdelays.
Also, correct tapdelay value settings at 40MHZ by modifying
the if check to <= instead of <.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Ashok Reddy Soma 
---

 drivers/spi/zynqmp_gqspi.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index ae7b70aa57..136c20f09e 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -282,24 +282,19 @@ void zynqmp_qspi_set_tapdelay(struct udevice *bus, u32 
baudrateval)
debug("%s, req_hz:%d, clk_rate:%d, baudrateval:%d\n",
  __func__, reqhz, clk_rate, baudrateval);

-   if (reqhz < GQSPI_FREQ_40MHZ) {
-   zynqmp_mmio_read(IOU_TAPDLY_BYPASS_OFST, );
-   tapdlybypass |= (TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
-   TAP_DLY_BYPASS_LQSPI_RX_SHIFT);
+   if (reqhz <= GQSPI_FREQ_40MHZ) {
+   tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
+   TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
} else if (reqhz <= GQSPI_FREQ_100MHZ) {
-   zynqmp_mmio_read(IOU_TAPDLY_BYPASS_OFST, );
-   tapdlybypass |= (TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
-   TAP_DLY_BYPASS_LQSPI_RX_SHIFT);
-   lpbkdlyadj = readl(>lpbkdly);
-   lpbkdlyadj |= (GQSPI_LPBK_DLY_ADJ_LPBK_MASK);
-   datadlyadj = readl(>gqspidlyadj);
-   datadlyadj |= ((GQSPI_USE_DATA_DLY << GQSPI_USE_DATA_DLY_SHIFT)
-   | (GQSPI_DATA_DLY_ADJ_VALUE <<
-   GQSPI_DATA_DLY_ADJ_SHIFT));
+   tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
+   TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
+   lpbkdlyadj = GQSPI_LPBK_DLY_ADJ_LPBK_MASK;
+   datadlyadj = (GQSPI_USE_DATA_DLY << GQSPI_USE_DATA_DLY_SHIFT) |
+ (GQSPI_DATA_DLY_ADJ_VALUE <<
+  GQSPI_DATA_DLY_ADJ_SHIFT);
} else if (reqhz <= GQSPI_FREQ_150MHZ) {
-   lpbkdlyadj = readl(>lpbkdly);
-   lpbkdlyadj |= ((GQSPI_LPBK_DLY_ADJ_LPBK_MASK) |
-   GQSPI_LPBK_DLY_ADJ_DLY_0);
+   lpbkdlyadj = GQSPI_LPBK_DLY_ADJ_LPBK_MASK |
+ GQSPI_LPBK_DLY_ADJ_DLY_0;
}

zynqmp_mmio_write(IOU_TAPDLY_BYPASS_OFST, IOU_TAPDLY_BYPASS_MASK,
--
2.17.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


[PATCH 1/7] spi: zynqmp_gqspi: do not round immediate_data field

2021-01-18 Thread Ashok Reddy Soma
From: Wojciech Tatarski 

Immediate_data is 8 bit value in generic FIFO command. When fields
data_xfer=1 and exponent=0 this field specifies the absolute number of data
bytes to read into the RXFIFO. Values from range 0xfd to 0xff are rounded
up to 0x100. It causes overwriting the next bit field which is data_xfer.
According to Zynq Ultrascale TRM only DMA transfers should be word aligned.
So there is no reason to round up the immediate_data field.

Signed-off-by: Wojciech Tatarski 
Signed-off-by: Tomasz Gorochowik 
Tested-by: Siva Durga Prasad Paladugu 
Signed-off-by: Ashok Reddy Soma 
---

 drivers/spi/zynqmp_gqspi.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index efcbd0557f..3e0dbb2c7b 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -524,7 +524,7 @@ static int zynqmp_qspi_start_dma(struct zynqmp_qspi_priv 
*priv,
 u32 gen_fifo_cmd, u32 *buf)
 {
u32 addr;
-   u32 size, len;
+   u32 size;
u32 actuallen = priv->len;
int ret = 0;
struct zynqmp_qspi_dma_regs *dma_regs = priv->dma_regs;
@@ -537,12 +537,7 @@ static int zynqmp_qspi_start_dma(struct zynqmp_qspi_priv 
*priv,
flush_dcache_range(addr, addr + size);

while (priv->len) {
-   len = zynqmp_qspi_calc_exp(priv, _fifo_cmd);
-   if (!(gen_fifo_cmd & GQSPI_GFIFO_EXP_MASK) &&
-   (len % ARCH_DMA_MINALIGN)) {
-   gen_fifo_cmd &= ~GENMASK(7, 0);
-   gen_fifo_cmd |= roundup(len, ARCH_DMA_MINALIGN);
-   }
+   zynqmp_qspi_calc_exp(priv, _fifo_cmd);
zynqmp_qspi_fill_gen_fifo(priv, gen_fifo_cmd);

debug("GFIFO_CMD_RX:0x%x\n", gen_fifo_cmd);
--
2.17.1

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


[PATCH 3/7] spi: zynqmp_gqspi: Add support for IO mode

2021-01-18 Thread Ashok Reddy Soma
Add support for device tree "has-io-mode" flag.
The driver will be in IO mode when "has-io-mode" is passed from device
tree instead of DMA.

Signed-off-by: Ashok Reddy Soma 
---

 drivers/spi/zynqmp_gqspi.c | 140 -
 1 file changed, 123 insertions(+), 17 deletions(-)

diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index 81c5e2b22f..ae7b70aa57 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -16,11 +16,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include "../mtd/spi/sf_internal.h"
+#include 

 #define GQSPI_GFIFO_STRT_MODE_MASK BIT(29)
 #define GQSPI_CONFIG_MODE_EN_MASK  (3 << 30)
@@ -38,6 +40,7 @@
 #define GQSPI_IXR_TXFULL_MASK  0x0008 /* QSPI TX FIFO is full */
 #define GQSPI_IXR_RXNEMTY_MASK 0x0010 /* QSPI RX FIFO Not Empty */
 #define GQSPI_IXR_GFEMTY_MASK  0x0080 /* QSPI Generic FIFO Empty */
+#define GQSPI_IXR_GFNFULL_MASK 0x0200 /* QSPI GENFIFO not full */
 #define GQSPI_IXR_ALL_MASK (GQSPI_IXR_TXNFULL_MASK | \
 GQSPI_IXR_RXNEMTY_MASK)

@@ -75,6 +78,7 @@

 #define GQSPI_GFIFO_SELECT BIT(0)
 #define GQSPI_FIFO_THRESHOLD   1
+#define GQSPI_GENFIFO_THRESHOLD31

 #define SPI_XFER_ON_BOTH   0
 #define SPI_XFER_ON_LOWER  1
@@ -161,6 +165,7 @@ struct zynqmp_qspi_plat {
struct zynqmp_qspi_dma_regs *dma_regs;
u32 frequency;
u32 speed_hz;
+   unsigned int io_mode;
 };

 struct zynqmp_qspi_priv {
@@ -173,8 +178,11 @@ struct zynqmp_qspi_priv {
int bytes_to_receive;
unsigned int is_inst;
unsigned int cs_change:1;
+   unsigned int io_mode;
 };

+static u8 last_cmd;
+
 static int zynqmp_qspi_of_to_plat(struct udevice *bus)
 {
struct zynqmp_qspi_plat *plat = dev_get_plat(bus);
@@ -186,6 +194,7 @@ static int zynqmp_qspi_of_to_plat(struct udevice *bus)
plat->dma_regs = (struct zynqmp_qspi_dma_regs *)
  (dev_read_addr(bus) + GQSPI_DMA_REG_OFFSET);

+   plat->io_mode = dev_read_bool(bus, "has-io-mode");
return 0;
 }

@@ -198,14 +207,20 @@ static void zynqmp_qspi_init_hw(struct zynqmp_qspi_priv 
*priv)
writel(GQSPI_GFIFO_ALL_INT_MASK, >idisr);
writel(GQSPI_FIFO_THRESHOLD, >txftr);
writel(GQSPI_FIFO_THRESHOLD, >rxftr);
+   writel(GQSPI_GENFIFO_THRESHOLD, >gqfthr);
writel(GQSPI_GFIFO_ALL_INT_MASK, >isr);
+   writel(0x0, >enbr);

config_reg = readl(>confr);
-   config_reg &= ~(GQSPI_GFIFO_STRT_MODE_MASK |
-   GQSPI_CONFIG_MODE_EN_MASK);
-   config_reg |= GQSPI_CONFIG_DMA_MODE |
- GQSPI_GFIFO_WP_HOLD |
- GQSPI_DFLT_BAUD_RATE_DIV;
+   config_reg &= ~(GQSPI_CONFIG_MODE_EN_MASK);
+   config_reg |= GQSPI_GFIFO_WP_HOLD | GQSPI_DFLT_BAUD_RATE_DIV;
+   if (priv->io_mode) {
+   config_reg |= GQSPI_GFIFO_STRT_MODE_MASK;
+   } else {
+   config_reg &= ~(GQSPI_GFIFO_STRT_MODE_MASK);
+   config_reg |= GQSPI_CONFIG_DMA_MODE;
+   }
+
writel(config_reg, >confr);

writel(GQSPI_ENABLE_ENABLE_MASK, >enbr);
@@ -215,8 +230,7 @@ static u32 zynqmp_qspi_bus_select(struct zynqmp_qspi_priv 
*priv)
 {
u32 gqspi_fifo_reg = 0;

-   gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS |
-GQSPI_GFIFO_CS_LOWER;
+   gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS | GQSPI_GFIFO_CS_LOWER;

return gqspi_fifo_reg;
 }
@@ -227,6 +241,7 @@ static void zynqmp_qspi_fill_gen_fifo(struct 
zynqmp_qspi_priv *priv,
struct zynqmp_qspi_regs *regs = priv->regs;
int ret = 0;

+   /* Wait until the fifo is not full to write the new command */
ret = wait_for_bit_le32(>isr, GQSPI_IXR_GFEMTY_MASK, 1,
GQSPI_TIMEOUT, 1);
if (ret)
@@ -343,6 +358,7 @@ static int zynqmp_qspi_probe(struct udevice *bus)

priv->regs = plat->regs;
priv->dma_regs = plat->dma_regs;
+   priv->io_mode = plat->io_mode;

ret = clk_get_by_index(bus, 0, );
if (ret < 0) {
@@ -363,7 +379,7 @@ static int zynqmp_qspi_probe(struct udevice *bus)
return ret;
}
plat->frequency = clock;
-   plat->speed_hz = plat->frequency / 2;
+   plat->speed_hz = plat->frequency;

/* init the zynq spi hw */
zynqmp_qspi_init_hw(priv);
@@ -395,7 +411,7 @@ static int zynqmp_qspi_set_mode(struct udevice *bus, uint 
mode)

 static int zynqmp_qspi_fill_tx_fifo(struct zynqmp_qspi_priv *priv, u32 size)
 {
-   u32 data;
+   u32 data, config_reg, ier;
int ret = 0;
struct zynqmp_qspi_regs *regs = priv->regs;
u32 *buf = (u32 *)priv->tx_buf;
@@ -404,6 +420,17 @@ static int zynqmp_qspi_fill_tx_fifo(struct 
zynqmp_qspi_priv *priv, 

  1   2   >