[PATCH v2 3/3] arm: dts: k3-am65/j721e: Sync DMA DT bindings from Kernel DT

2020-06-29 Thread Vignesh Raghavendra
Sync DT bindings from kernel DT and move them to out of -u-boot.dtsi
files.

Signed-off-by: Vignesh Raghavendra 
Reviewed-by: Grygorii Strashko 
---
 arch/arm/dts/k3-am65-mcu.dtsi |  44 +++
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi  | 121 ++
 .../k3-j721e-common-proc-board-u-boot.dtsi| 118 ++---
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi |  43 +++
 include/dt-bindings/dma/k3-udma.h |  31 -
 5 files changed, 112 insertions(+), 245 deletions(-)
 delete mode 100644 include/dt-bindings/dma/k3-udma.h

diff --git a/arch/arm/dts/k3-am65-mcu.dtsi b/arch/arm/dts/k3-am65-mcu.dtsi
index bc9a87210d..d1a9fb5de6 100644
--- a/arch/arm/dts/k3-am65-mcu.dtsi
+++ b/arch/arm/dts/k3-am65-mcu.dtsi
@@ -102,4 +102,48 @@
#size-cells = <0>;
};
};
+
+   mcu_navss {
+   compatible = "simple-mfd";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   dma-coherent;
+   dma-ranges;
+
+   ti,sci-dev-id = <119>;
+
+   mcu_ringacc: ringacc@2b80 {
+   compatible = "ti,am654-navss-ringacc";
+   reg =   <0x0 0x2b80 0x0 0x40>,
+   <0x0 0x2b00 0x0 0x40>,
+   <0x0 0x2859 0x0 0x100>,
+   <0x0 0x2a50 0x0 0x4>;
+   reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target";
+   ti,num-rings = <286>;
+   ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
+   ti,dma-ring-reset-quirk;
+   ti,sci = <>;
+   ti,sci-dev-id = <195>;
+   };
+
+   mcu_udmap: dma-controller@285c {
+   compatible = "ti,am654-navss-mcu-udmap";
+   reg =   <0x0 0x285c 0x0 0x100>,
+   <0x0 0x2a80 0x0 0x4>,
+   <0x0 0x2aa0 0x0 0x4>;
+   reg-names = "gcfg", "rchanrt", "tchanrt";
+   #dma-cells = <1>;
+
+   ti,sci = <>;
+   ti,sci-dev-id = <194>;
+   ti,ringacc = <_ringacc>;
+
+   ti,sci-rm-range-tchan = <0x1>, /* TX_HCHAN */
+   <0x2>; /* TX_CHAN */
+   ti,sci-rm-range-rchan = <0x3>, /* RX_HCHAN */
+   <0x4>; /* RX_CHAN */
+   ti,sci-rm-range-rflow = <0x5>; /* GP RFLOW */
+   };
+   };
 };
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi 
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index a7e5eb0553..1a40fa12b7 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -4,7 +4,6 @@
  */
 
 #include 
-#include 
 #include 
 
 / {
@@ -47,51 +46,14 @@
 _mcu {
u-boot,dm-spl;
 
-   navss_mcu: navss-mcu {
-   compatible = "simple-bus";
-   #address-cells = <2>;
-   #size-cells = <2>;
-   ranges;
+   mcu_navss {
u-boot,dm-spl;
 
-   ti,sci-dev-id = <119>;
-
-   mcu_ringacc: ringacc@2b80 {
-   compatible = "ti,am654-navss-ringacc";
-   reg =   <0x0 0x2b80 0x0 0x40>,
-   <0x0 0x2b00 0x0 0x40>,
-   <0x0 0x2859 0x0 0x100>,
-   <0x0 0x2a50 0x0 0x4>;
-   reg-names = "rt", "fifos",
-   "proxy_gcfg", "proxy_target";
-   ti,num-rings = <286>;
-   ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
-   ti,dma-ring-reset-quirk;
-   ti,sci = <>;
-   ti,sci-dev-id = <195>;
+   ringacc@2b80 {
u-boot,dm-spl;
};
 
-   mcu_udmap: udmap@285c {
-   compatible = "ti,k3-navss-udmap";
-   reg =   <0x0 0x285c 0x0 0x100>,
-   <0x0 0x2a80 0x0 0x4>,
-   <0x0 0x2aa0 0x0 0x4>;
-   reg-names = "gcfg", "rchanrt", "tchanrt";
-   #dma-cells = <3>;
-
-   ti,ringacc = <_ringacc>;
-   ti,psil-base = <0x6000>;
-
-   ti,sci = <>;
-   ti,sci-dev-id = <194>;
-
-   ti,sci-rm-range-tchan = <0x1>, /* TX_HCHAN */
-   <0x2>; /* TX_CHAN */
-   ti,sci-rm-range-rchan = <0x3>, 

[PATCH v2 1/3] dma: ti: Add static PSIL endpoint information

2020-06-29 Thread Vignesh Raghavendra
Much of PSIL endpoint configuration for a given SoC can be known at
compile time, therefore pass them for platform specific data instead of
DT.

Add per SoC's specific PSIL endpoint data. This is to bring driver in
sync with upstream DT.

Signed-off-by: Vignesh Raghavendra 
Reviewed-by: Grygorii Strashko 
---
 drivers/dma/ti/Kconfig |   3 +
 drivers/dma/ti/Makefile|   1 +
 drivers/dma/ti/k3-psil-am654.c | 175 ++
 drivers/dma/ti/k3-psil-j721e.c | 222 +
 drivers/dma/ti/k3-psil-priv.h  |  43 +++
 drivers/dma/ti/k3-psil.c   |  42 +++
 drivers/dma/ti/k3-psil.h   |  67 ++
 7 files changed, 553 insertions(+)
 create mode 100644 drivers/dma/ti/k3-psil-am654.c
 create mode 100644 drivers/dma/ti/k3-psil-j721e.c
 create mode 100644 drivers/dma/ti/k3-psil-priv.h
 create mode 100644 drivers/dma/ti/k3-psil.c
 create mode 100644 drivers/dma/ti/k3-psil.h

diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig
index 3d5498326c..9d7a1efb2b 100644
--- a/drivers/dma/ti/Kconfig
+++ b/drivers/dma/ti/Kconfig
@@ -12,3 +12,6 @@ config TI_K3_NAVSS_UDMA
 help
   Support for UDMA used in K3 devices.
 endif
+
+config TI_K3_PSIL
+   bool
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index de2f9ac91a..d6999573b8 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 obj-$(CONFIG_TI_K3_NAVSS_UDMA) += k3-udma.o
+obj-$(CONFIG_TI_K3_PSIL) += k3-psil.o k3-psil-am654.o k3-psil-j721e.o
diff --git a/drivers/dma/ti/k3-psil-am654.c b/drivers/dma/ti/k3-psil-am654.c
new file mode 100644
index 00..a896a15908
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-am654.c
@@ -0,0 +1,175 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *  Author: Peter Ujfalusi 
+ */
+
+#include 
+
+#include "k3-psil-priv.h"
+
+#define PSIL_PDMA_XY_TR(x) \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_PDMA_XY, \
+   },  \
+   }
+
+#define PSIL_PDMA_XY_PKT(x)\
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_PDMA_XY, \
+   .pkt_mode = 1,  \
+   },  \
+   }
+
+#define PSIL_ETHERNET(x)   \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_NATIVE,  \
+   .pkt_mode = 1,  \
+   .needs_epib = 1,\
+   .psd_size = 16, \
+   },  \
+   }
+
+#define PSIL_SA2UL(x, tx)  \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_NATIVE,  \
+   .pkt_mode = 1,  \
+   .needs_epib = 1,\
+   .psd_size = 64, \
+   .notdpkt = tx,  \
+   },  \
+   }
+
+/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
+static struct psil_ep am654_src_ep_map[] = {
+   /* SA2UL */
+   PSIL_SA2UL(0x4000, 0),
+   PSIL_SA2UL(0x4001, 0),
+   PSIL_SA2UL(0x4002, 0),
+   PSIL_SA2UL(0x4003, 0),
+   /* PRU_ICSSG0 */
+   PSIL_ETHERNET(0x4100),
+   PSIL_ETHERNET(0x4101),
+   PSIL_ETHERNET(0x4102),
+   PSIL_ETHERNET(0x4103),
+   /* PRU_ICSSG1 */
+   PSIL_ETHERNET(0x4200),
+   PSIL_ETHERNET(0x4201),
+   PSIL_ETHERNET(0x4202),
+   PSIL_ETHERNET(0x4203),
+   /* PRU_ICSSG2 */
+   PSIL_ETHERNET(0x4300),
+   PSIL_ETHERNET(0x4301),
+   PSIL_ETHERNET(0x4302),
+   PSIL_ETHERNET(0x4303),
+   /* PDMA0 - McASPs */
+   PSIL_PDMA_XY_TR(0x4400),
+   PSIL_PDMA_XY_TR(0x4401),
+   PSIL_PDMA_XY_TR(0x4402),
+   /* PDMA1 - SPI0-4 */
+   PSIL_PDMA_XY_PKT(0x4500),
+   PSIL_PDMA_XY_PKT(0x4501),
+   PSIL_PDMA_XY_PKT(0x4502),
+   PSIL_PDMA_XY_PKT(0x4503),
+   PSIL_PDMA_XY_PKT(0x4504),
+   PSIL_PDMA_XY_PKT(0x4505),
+   PSIL_PDMA_XY_PKT(0x4506),
+   PSIL_PDMA_XY_PKT(0x4507),

[PATCH v2 0/3] Sync UDMA bindings from kernel

2020-06-29 Thread Vignesh Raghavendra
UDMA DT bindings have deviated from kernel's DT for AM654 and J721e.
This series updates UDMA driver and sync DT bindings

Tested OSPI and CPSW on AM654 and J721e after the changes

v2:
Collect R-by
Update patch 2/3 to note about DT incompatibility

Vignesh Raghavendra (3):
  dma: ti: Add static PSIL endpoint information
  dma: ti: k3-udma: Update driver to use static endpoint Data
  arm: dts: k3-am65/j721e: Sync DMA DT bindings from Kernel DT

 arch/arm/dts/k3-am65-mcu.dtsi |  44 
 arch/arm/dts/k3-am654-base-board-u-boot.dtsi  | 121 +-
 .../k3-j721e-common-proc-board-u-boot.dtsi| 118 +-
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi |  43 
 drivers/dma/ti/Kconfig|   4 +
 drivers/dma/ti/Makefile   |   1 +
 drivers/dma/ti/k3-psil-am654.c| 175 ++
 drivers/dma/ti/k3-psil-j721e.c| 222 ++
 drivers/dma/ti/k3-psil-priv.h |  43 
 drivers/dma/ti/k3-psil.c  |  42 
 drivers/dma/ti/k3-psil.h  |  67 ++
 drivers/dma/ti/k3-udma.c  | 145 
 include/dt-bindings/dma/k3-udma.h |  31 ---
 13 files changed, 768 insertions(+), 288 deletions(-)
 create mode 100644 drivers/dma/ti/k3-psil-am654.c
 create mode 100644 drivers/dma/ti/k3-psil-j721e.c
 create mode 100644 drivers/dma/ti/k3-psil-priv.h
 create mode 100644 drivers/dma/ti/k3-psil.c
 create mode 100644 drivers/dma/ti/k3-psil.h
 delete mode 100644 include/dt-bindings/dma/k3-udma.h

-- 
2.27.0



[PATCH v2 2/3] dma: ti: k3-udma: Update driver to use static endpoint Data

2020-06-29 Thread Vignesh Raghavendra
Update driver to use static PSIL endpoint Data instead of DT. This will
allow DT bindings to be in sync with kernel's DT.

Note that this patch breaks networking and OSPI boot as driver changes
are not backward compatible with existing DT. Subsequent commit will
update the DT to make it compatible with updated driver.

Signed-off-by: Vignesh Raghavendra 
Reviewed-by: Grygorii Strashko 
---
 drivers/dma/ti/Kconfig   |   1 +
 drivers/dma/ti/k3-udma.c | 145 +++
 2 files changed, 103 insertions(+), 43 deletions(-)

diff --git a/drivers/dma/ti/Kconfig b/drivers/dma/ti/Kconfig
index 9d7a1efb2b..9cbd5f334d 100644
--- a/drivers/dma/ti/Kconfig
+++ b/drivers/dma/ti/Kconfig
@@ -8,6 +8,7 @@ config TI_K3_NAVSS_UDMA
 select DMA
 select TI_K3_NAVSS_RINGACC
 select TI_K3_NAVSS_PSILCFG
+select TI_K3_PSIL
 default n
 help
   Support for UDMA used in K3 devices.
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 2ce16c8e27..5fc8692e19 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -31,6 +30,7 @@
 #include 
 
 #include "k3-udma-hwdef.h"
+#include "k3-psil-priv.h"
 
 #if BITS_PER_LONG == 64
 #define RINGACC_RING_USE_PROXY (0)
@@ -69,6 +69,21 @@ struct udma_rchan {
struct k3_nav_ring *r_ring; /* Receive ring*/
 };
 
+#define UDMA_FLAG_PDMA_ACC32   BIT(0)
+#define UDMA_FLAG_PDMA_BURST   BIT(1)
+#define UDMA_FLAG_TDTYPE   BIT(2)
+
+struct udma_match_data {
+   u32 psil_base;
+   bool enable_memcpy_support;
+   u32 flags;
+   u32 statictr_z_mask;
+   u32 rchan_oes_offset;
+
+   u8 tpl_levels;
+   u32 level_start_idx[];
+};
+
 struct udma_rflow {
int id;
 };
@@ -114,6 +129,8 @@ struct udma_dev {
struct udma_rchan *rchans;
struct udma_rflow *rflows;
 
+   struct udma_match_data *match_data;
+
struct udma_chan *channels;
u32 psil_base;
 
@@ -1293,12 +1310,8 @@ static int udma_probe(struct udevice *dev)
if (IS_ERR(ud->ringacc))
return PTR_ERR(ud->ringacc);
 
-   ud->psil_base = dev_read_u32_default(dev, "ti,psil-base", 0);
-   if (!ud->psil_base) {
-   dev_info(dev,
-"Missing ti,psil-base property, using %d.\n", ret);
-   return -EINVAL;
-   }
+   ud->match_data = (void *)dev_get_driver_data(dev);
+   ud->psil_base = ud->match_data->psil_base;
 
ret = uclass_get_device_by_phandle(UCLASS_FIRMWARE, dev,
   "ti,sci", _dev);
@@ -1723,8 +1736,7 @@ static int udma_of_xlate(struct dma *dma, struct 
ofnode_phandle_args *args)
 {
struct udma_dev *ud = dev_get_priv(dma->dev);
struct udma_chan *uc = >channels[0];
-   ofnode chconf_node, slave_node;
-   char prop[50];
+   struct psil_endpoint_config *ep_config;
u32 val;
 
for (val = 0; val < ud->ch_count; val++) {
@@ -1736,42 +1748,26 @@ static int udma_of_xlate(struct dma *dma, struct 
ofnode_phandle_args *args)
if (val == ud->ch_count)
return -EBUSY;
 
-   uc->dir = DMA_DEV_TO_MEM;
-   if (args->args[2] == UDMA_DIR_TX)
+   uc->slave_thread_id = args->args[0];
+   if (uc->slave_thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)
uc->dir = DMA_MEM_TO_DEV;
+   else
+   uc->dir = DMA_DEV_TO_MEM;
 
-   slave_node = ofnode_get_by_phandle(args->args[0]);
-   if (!ofnode_valid(slave_node)) {
-   dev_err(ud->dev, "slave node is missing\n");
-   return -EINVAL;
-   }
-
-   snprintf(prop, sizeof(prop), "ti,psil-config%u", args->args[1]);
-   chconf_node = ofnode_find_subnode(slave_node, prop);
-   if (!ofnode_valid(chconf_node)) {
-   dev_err(ud->dev, "Channel configuration node is missing\n");
-   return -EINVAL;
-   }
-
-   if (!ofnode_read_u32(chconf_node, "linux,udma-mode", )) {
-   if (val == UDMA_PKT_MODE)
-   uc->pkt_mode = true;
+   ep_config = psil_get_ep_config(uc->slave_thread_id);
+   if (IS_ERR(ep_config)) {
+   dev_err(ud->dev, "No configuration for psi-l thread 0x%04x\n",
+   uc->slave_thread_id);
+   uc->dir = DMA_MEM_TO_MEM;
+   uc->slave_thread_id = -1;
+   return false;
}
 
-   if (!ofnode_read_u32(chconf_node, "statictr-type", ))
-   uc->static_tr_type = val;
+   uc->pkt_mode = ep_config->pkt_mode;
 
-   uc->needs_epib = ofnode_read_bool(chconf_node, "ti,needs-epib");
-   if (!ofnode_read_u32(chconf_node, "ti,psd-size", ))
-   uc->psd_size = val;
-   uc->metadata_size = (uc->needs_epib ? 16 : 0) + uc->psd_size;
-
-   if (ofnode_read_u32(slave_node, "ti,psil-base", )) {
- 

Re: [PATCH v1 12/43] x86: Add bindings for NHLT

2020-06-29 Thread Bin Meng
Hi Simon,

On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> Add devicetree bindings for the Intel Non-High-Definition-Audio Link Table
> (NHLT).
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/dt-bindings/sound/nhlt.h | 23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 include/dt-bindings/sound/nhlt.h
>
> diff --git a/include/dt-bindings/sound/nhlt.h 
> b/include/dt-bindings/sound/nhlt.h
> new file mode 100644
> index 00..c33f874966
> --- /dev/null
> +++ b/include/dt-bindings/sound/nhlt.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2019 Google LLC
> + */
> +
> +#ifndef _DT_BINDINGS_SOUND_NHLT_H
> +#define _DT_BINDINGS_SOUND_NHLT_H
> +
> +#define NHLT_VID   0x8086
> +#define NHLT_DID_DMIC  0xae20
> +#define NHLT_DID_BT0xae30
> +#define NHLT_DID_SSP   0xae34

These look like PCI vendor ID (0x8086 for Intel) and device IDs. If
they are device IDs, how could they be fixed?

> +
> +/* Hardware links available to use for codecs */
> +#define AUDIO_LINK_SSP00
> +#define AUDIO_LINK_SSP11
> +#define AUDIO_LINK_SSP22
> +#define AUDIO_LINK_SSP33
> +#define AUDIO_LINK_SSP44
> +#define AUDIO_LINK_SSP55
> +#define AUDIO_LINK_DMIC6
> +
> +#endif /* _DT_BINDINGS_SOUND_NHLT_H */
> --

Regards,
Bin


Re: [PATCH v1 13/43] acpi: Support generation of a device

2020-06-29 Thread Bin Meng
On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> Allow writing an ACPI device to the generated ACPI code.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/acpi/acpigen.h |  9 +
>  lib/acpi/acpigen.c |  7 +++
>  test/dm/acpigen.c  | 27 +++
>  3 files changed, 43 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 11/43] acpi: mmc: Generate ACPI info for the PCI SD Card

2020-06-29 Thread Bin Meng
Hi Simon,

On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> Write required information into the SSDT to describe the SD card
> card-detect pin. Since the required GPIO properties are not present in
> the device-tree binding, set them manually for now.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v1:
> - Capitalise ACPI_OPS_PTR
>
>  configs/sandbox_defconfig |  2 +
>  drivers/mmc/pci_mmc.c | 78 ++-
>  2 files changed, 79 insertions(+), 1 deletion(-)
>
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index 982075c568..cb6b4b0ee7 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -143,7 +143,9 @@ CONFIG_P2SB=y
>  CONFIG_PWRSEQ=y
>  CONFIG_SPL_PWRSEQ=y
>  CONFIG_I2C_EEPROM=y
> +CONFIG_MMC_PCI=y
>  CONFIG_MMC_SANDBOX=y
> +CONFIG_MMC_SDHCI=y
>  CONFIG_MTD=y
>  CONFIG_SPI_FLASH_SANDBOX=y
>  CONFIG_SPI_FLASH_ATMEL=y
> diff --git a/drivers/mmc/pci_mmc.c b/drivers/mmc/pci_mmc.c
> index 404264a697..0c45e1b893 100644
> --- a/drivers/mmc/pci_mmc.c
> +++ b/drivers/mmc/pci_mmc.c
> @@ -7,10 +7,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>
>  struct pci_mmc_plat {
> struct mmc_config cfg;
> @@ -20,6 +25,7 @@ struct pci_mmc_plat {
>  struct pci_mmc_priv {
> struct sdhci_host host;
> void *base;
> +   struct gpio_desc cd_gpio;
>  };
>
>  static int pci_mmc_probe(struct udevice *dev)
> @@ -44,6 +50,15 @@ static int pci_mmc_probe(struct udevice *dev)
> return sdhci_probe(dev);
>  }
>
> +static int pci_mmc_ofdata_to_platdata(struct udevice *dev)
> +{
> +   struct pci_mmc_priv *priv = dev_get_priv(dev);
> +
> +   gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio, GPIOD_IS_IN);
> +
> +   return 0;
> +}
> +
>  static int pci_mmc_bind(struct udevice *dev)
>  {
> struct pci_mmc_plat *plat = dev_get_platdata(dev);
> @@ -51,14 +66,75 @@ static int pci_mmc_bind(struct udevice *dev)
> return sdhci_bind(dev, >mmc, >cfg);
>  }
>
> +static int pci_mmc_acpi_fill_ssdt(const struct udevice *dev,
> + struct acpi_ctx *ctx)
> +{
> +   struct pci_mmc_priv *priv = dev_get_priv(dev);
> +   char path[ACPI_PATH_MAX];
> +   struct acpi_gpio gpio;
> +   struct acpi_dp *dp;
> +   int ret;
> +
> +   if (!dev_of_valid(dev))
> +   return 0;
> +
> +   ret = gpio_get_acpi(>cd_gpio, );
> +   if (ret)
> +   return log_msg_ret("gpio", ret);
> +   gpio.type = ACPI_GPIO_TYPE_INTERRUPT;
> +   gpio.pull = ACPI_GPIO_PULL_NONE;
> +   gpio.irq.mode = ACPI_IRQ_EDGE_TRIGGERED;
> +   gpio.irq.polarity = ACPI_IRQ_ACTIVE_BOTH;
> +   gpio.irq.shared = ACPI_IRQ_SHARED;
> +   gpio.irq.wake = ACPI_IRQ_WAKE;

The above are all hardcoded. Is there is way to figure out these from
DT GPIO properties?

> +   gpio.interrupt_debounce_timeout = 1; /* 100ms */
> +
> +   /* Use device path as the Scope for the SSDT */
> +   ret = acpi_device_path(dev, path, sizeof(path));
> +   if (ret)
> +   return log_msg_ret("path", ret);
> +   acpigen_write_scope(ctx, path);
> +   acpigen_write_name(ctx, "_CRS");
> +
> +   /* Write GpioInt() as default (if set) or custom from devicetree */
> +   acpigen_write_resourcetemplate_header(ctx);
> +   acpi_device_write_gpio(ctx, );
> +   acpigen_write_resourcetemplate_footer(ctx);
> +
> +   /* Bind the cd-gpio name to the GpioInt() resource */
> +   dp = acpi_dp_new_table("_DSD");
> +   if (!dp)
> +   return -ENOMEM;
> +   acpi_dp_add_gpio(dp, "cd-gpio", path, 0, 0, 1);
> +   ret = acpi_dp_write(ctx, dp);
> +   if (ret)
> +   return log_msg_ret("cd", ret);
> +
> +   acpigen_pop_len(ctx);
> +
> +   return 0;
> +}
> +
> +struct acpi_ops pci_mmc_acpi_ops = {
> +   .fill_ssdt  = pci_mmc_acpi_fill_ssdt,
> +};
> +
> +static const struct udevice_id pci_mmc_match[] = {
> +   { .compatible = "intel,apl-sd" },
> +   { }
> +};
> +
>  U_BOOT_DRIVER(pci_mmc) = {
> .name   = "pci_mmc",
> .id = UCLASS_MMC,
> +   .of_match = pci_mmc_match,
> .bind   = pci_mmc_bind,
> +   .ofdata_to_platdata = pci_mmc_ofdata_to_platdata,
> .probe  = pci_mmc_probe,
> .ops= _ops,
> .priv_auto_alloc_size = sizeof(struct pci_mmc_priv),
> .platdata_auto_alloc_size = sizeof(struct pci_mmc_plat),
> +   ACPI_OPS_PTR(_mmc_acpi_ops)
>  };
>
>  static struct pci_device_id mmc_supported[] = {

Regards,
Bin


Re: [PATCH v1 14/43] acpi: Support writing named values

2020-06-29 Thread Bin Meng
On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> Allow writing named integers and strings to the generated ACPI code.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/acpi/acpigen.h | 72 ++
>  lib/acpi/acpigen.c | 49 ++
>  test/dm/acpigen.c  | 78 ++
>  3 files changed, 199 insertions(+)
>

Reviewed-by: Bin Meng 


[PATCH] configs: powerpc: add usb (host) mass storage support

2020-06-29 Thread Ran Wang
commit 0cfccb54014b ("configs: Resync with savedefconfig")
removed CONFIG_USB_STORAGE from some powerpc platforms' defconfig
files, whicih would block the use case of system loading rootfs
from USB drives, add them back.

Signed-off-by: Ran Wang 
---
 configs/P1020RDB-PC_36BIT_NAND_defconfig | 1 +
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig   | 1 +
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 1 +
 configs/P1020RDB-PC_36BIT_defconfig  | 1 +
 configs/P1020RDB-PC_NAND_defconfig   | 1 +
 configs/P1020RDB-PC_SDCARD_defconfig | 1 +
 configs/P1020RDB-PC_SPIFLASH_defconfig   | 1 +
 configs/P1020RDB-PC_defconfig| 1 +
 configs/P1020RDB-PD_NAND_defconfig   | 1 +
 configs/P1020RDB-PD_SDCARD_defconfig | 1 +
 configs/P1020RDB-PD_SPIFLASH_defconfig   | 1 +
 configs/P1020RDB-PD_defconfig| 1 +
 configs/P2020RDB-PC_36BIT_NAND_defconfig | 1 +
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig   | 1 +
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 1 +
 configs/P2020RDB-PC_36BIT_defconfig  | 1 +
 configs/P2020RDB-PC_NAND_defconfig   | 1 +
 configs/P2020RDB-PC_SPIFLASH_defconfig   | 1 +
 configs/P2020RDB-PC_defconfig| 1 +
 configs/P2041RDB_NAND_defconfig  | 1 +
 configs/P2041RDB_SDCARD_defconfig| 1 +
 configs/P2041RDB_SPIFLASH_defconfig  | 1 +
 configs/P2041RDB_defconfig   | 1 +
 configs/P3041DS_NAND_defconfig   | 1 +
 configs/P3041DS_SDCARD_defconfig | 1 +
 configs/P3041DS_SPIFLASH_defconfig   | 1 +
 configs/P3041DS_defconfig| 1 +
 configs/P4080DS_SDCARD_defconfig | 1 +
 configs/P4080DS_SPIFLASH_defconfig   | 1 +
 configs/P4080DS_defconfig| 1 +
 configs/P5040DS_NAND_defconfig   | 1 +
 configs/P5040DS_SDCARD_defconfig | 1 +
 configs/P5040DS_SPIFLASH_defconfig   | 1 +
 configs/P5040DS_defconfig| 1 +
 configs/T1024RDB_NAND_defconfig  | 1 +
 configs/T1024RDB_SDCARD_defconfig| 1 +
 configs/T1024RDB_SPIFLASH_defconfig  | 1 +
 configs/T1024RDB_defconfig   | 1 +
 configs/T1042D4RDB_NAND_defconfig| 1 +
 configs/T1042D4RDB_SDCARD_defconfig  | 1 +
 configs/T1042D4RDB_SPIFLASH_defconfig| 1 +
 configs/T1042D4RDB_defconfig | 1 +
 configs/T2080RDB_NAND_defconfig  | 1 +
 configs/T2080RDB_SDCARD_defconfig| 1 +
 configs/T2080RDB_SPIFLASH_defconfig  | 1 +
 configs/T2080RDB_defconfig   | 1 +
 configs/T4240RDB_SDCARD_defconfig| 1 +
 configs/T4240RDB_defconfig   | 1 +
 48 files changed, 48 insertions(+)

diff --git a/configs/P1020RDB-PC_36BIT_NAND_defconfig 
b/configs/P1020RDB-PC_36BIT_NAND_defconfig
index 6ee52fe..7e32dbe 100644
--- a/configs/P1020RDB-PC_36BIT_NAND_defconfig
+++ b/configs/P1020RDB-PC_36BIT_NAND_defconfig
@@ -82,4 +82,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
 CONFIG_USB=y
+CONFIG_USB_STORAGE=y
 CONFIG_DM_USB=y
diff --git a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig 
b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
index 489b91d..1ad4cd8 100644
--- a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
+++ b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
@@ -77,4 +77,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
 CONFIG_USB=y
+CONFIG_USB_STORAGE=y
 CONFIG_DM_USB=y
diff --git a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig 
b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
index 4a8e4e3..ba2a68e 100644
--- a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
+++ b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
@@ -79,4 +79,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
 CONFIG_USB=y
+CONFIG_USB_STORAGE=y
 CONFIG_DM_USB=y
diff --git a/configs/P1020RDB-PC_36BIT_defconfig 
b/configs/P1020RDB-PC_36BIT_defconfig
index f9a4b73..508806b 100644
--- a/configs/P1020RDB-PC_36BIT_defconfig
+++ b/configs/P1020RDB-PC_36BIT_defconfig
@@ -66,4 +66,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
 CONFIG_USB=y
+CONFIG_USB_STORAGE=y
 CONFIG_DM_USB=y
diff --git a/configs/P1020RDB-PC_NAND_defconfig 
b/configs/P1020RDB-PC_NAND_defconfig
index 5c8231c..7e844da 100644
--- a/configs/P1020RDB-PC_NAND_defconfig
+++ b/configs/P1020RDB-PC_NAND_defconfig
@@ -81,4 +81,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
 CONFIG_USB=y
+CONFIG_USB_STORAGE=y
 CONFIG_DM_USB=y
diff --git a/configs/P1020RDB-PC_SDCARD_defconfig 
b/configs/P1020RDB-PC_SDCARD_defconfig
index ad2bb90..32f9902 100644
--- a/configs/P1020RDB-PC_SDCARD_defconfig
+++ b/configs/P1020RDB-PC_SDCARD_defconfig
@@ -76,4 +76,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
 CONFIG_USB=y
+CONFIG_USB_STORAGE=y
 CONFIG_DM_USB=y
diff --git a/configs/P1020RDB-PC_SPIFLASH_defconfig 
b/configs/P1020RDB-PC_SPIFLASH_defconfig
index b8055e4..36e3026 100644
--- a/configs/P1020RDB-PC_SPIFLASH_defconfig

Re: [PATCH v3 06/15] board: ns3: default reset type to L3

2020-06-29 Thread Rayagonda Kokatanur
Hi Simon,

On Fri, Jun 26, 2020 at 6:42 AM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur
>  wrote:
> >
> > Default "reset" from u-boot to L3 reset.
>
> U-Boot

Thank you, will fix this.
>
> > "reset" command with argument will trigger L1 reset.
> >
> > Signed-off-by: Rajesh Ravi 
> > Signed-off-by: Bharat Kumar Reddy Gooty 
> > Signed-off-by: Rayagonda Kokatanur 
> > ---
> >  board/broadcom/bcmns3/ns3.c | 20 ++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
> > index 5e644bd466..1221f26ddc 100644
> > --- a/board/broadcom/bcmns3/ns3.c
> > +++ b/board/broadcom/bcmns3/ns3.c
> > @@ -68,7 +68,23 @@ int dram_init_banksize(void)
> > return 0;
> >  }
> >
> > -void reset_cpu(ulong addr)
> > +void reset_cpu(ulong level)
> >  {
>
> This should be in a sysreset driver. It supports different reset types.

I checked the sysreset driver and found a generic/common psci driver -
drivers/sysreset/sysreset_psci.c.
We could use this common driver in our platform.

Right now this common driver uses the same command or function_id for
both WARM and COLD reset.
But in our case we should use different commands for WARM and COLD reset.

I am planning to add one kconfig option (USE_FN64_CMD) through which
we can select different commands or the same command for COLD reset.

Something like this,

static int psci_sysreset_request(struct udevice *dev, enum sysreset_t type)
{
unsigned long function_id;

switch (type) {
case SYSRESET_WARM:
 function_id = PSCI_0_2_FN_SYSTEM_RESET;
 break;

 case SYSRESET_COLD:
 if (CONFIG_IS_ENABLED(USE_FN64_CMD))
  function_id = PSCI_0_2_FN64_SYSTEM_RESET;
 else
  function_id = PSCI_0_2_FN_SYSTEM_RESET;
 break;

 case SYSRESET_POWER_OFF:
 function_id = PSCI_0_2_FN_SYSTEM_OFF;
 break;

 default:
 return -ENOSYS;
}

invoke_psci_fn(function_id, 0, 0, 0);

return -EINPROGRESS;
}

This way any platform can define/select USE_FN64_CMD if they need
different commands for WARM reset.
Please let me know about this approach.

Best regards,
Rayagonda

>
> > -   psci_system_reset();
> > +#define L3_RESET 30
> > +   u32 reset_level, strap_val;
> > +
> > +   /* Default reset type is L3 reset */
> > +   if (!level) {
> > +   /*
> > +* Encoding: u-boot reset command expects decimal argument
> > +* strap val = 1st decimal digit;reset level = 2nd decimal 
> > digit
> > +*/
> > +   strap_val = L3_RESET % 10;
> > +   level = L3_RESET / 10;
> > +   reset_level = level % 10;
> > +   psci_system_reset2(reset_level, strap_val);
> > +   } else {
> > +   /* U-boot cmd "reset" with any arg will trigger L1 reset */
> > +   psci_system_reset();
> > +   }
> >  }
> > --
> > 2.17.1
> >
>
> Regards,
> Simon


Re: [PATCH v1 10/43] acpi: Support generation of a generic register

2020-06-29 Thread Bin Meng
On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> Allow writing out a generic register.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/acpi/acpi_device.h |  1 +
>  include/acpi/acpigen.h | 28 +++
>  lib/acpi/acpigen.c | 71 ++
>  test/dm/acpigen.c  | 46 
>  4 files changed, 146 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 08/43] acpi: Export functions to write sized values

2020-06-29 Thread Bin Meng
Hi Simon,

On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> At present only acpigen_write_integer() is exported for use by other code.
> But in some cases it is useful to call the specific function depending on
> the size of the value.
>
> Export these functions and add a test.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/acpi/acpigen.h | 46 ++
>  test/dm/acpigen.c  | 45 -
>  2 files changed, 90 insertions(+), 1 deletion(-)
>

Since the acpigen_write_integer() patch has not been applied, could
you please squash this patch into:

[v3,15/35] acpi: Support writing an integer
http://patchwork.ozlabs.org/project/uboot/patch/20200614025523.40183-5-...@chromium.org/

Regards,
Bin


Re: [PATCH v1 07/43] dm: acpi: Add support for the NHLT table

2020-06-29 Thread Bin Meng
Hi Simon,

On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> The Intel Non-High-Definition-Audio Link Table (NHLT) table describes the
> audio codecs and connections in a system. Various devices can contribute
> information to produce the table.
>
> Add core support for this, based on a structure which is built up through
> calls to the driver.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/core/acpi.c | 15 +++
>  include/dm/acpi.h   | 26 ++
>  2 files changed, 41 insertions(+)
>
> diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
> index ea304a3067..a5053fec6f 100644
> --- a/drivers/core/acpi.c
> +++ b/drivers/core/acpi.c
> @@ -31,6 +31,7 @@ enum method_t {
> METHOD_WRITE_TABLES,
> METHOD_FILL_SSDT,
> METHOD_INJECT_DSDT,
> +   METHOD_SETUP_NHLT,

Do we really need to promote this to be an ACPI core method? Can we
reuse the SSDT/DSDT one?

>  };
>
>  /* Prototype for all methods */
> @@ -239,6 +240,8 @@ acpi_method acpi_get_method(struct udevice *dev, enum 
> method_t method)
> return aops->fill_ssdt;
> case METHOD_INJECT_DSDT:
> return aops->inject_dsdt;
> +   case METHOD_SETUP_NHLT:
> +   return aops->setup_nhlt;
> }
> }
>
> @@ -325,3 +328,15 @@ int acpi_write_dev_tables(struct acpi_ctx *ctx)
>
> return ret;
>  }
> +
> +int acpi_setup_nhlt(struct acpi_ctx *ctx, struct nhlt *nhlt)
> +{
> +   int ret;
> +
> +   log_debug("Setup NHLT\n");
> +   ctx->nhlt = nhlt;
> +   ret = acpi_recurse_method(ctx, dm_root(), METHOD_SETUP_NHLT, 
> TYPE_NONE);
> +   log_debug("Setup finished, err=%d\n", ret);
> +
> +   return ret;
> +}
> diff --git a/include/dm/acpi.h b/include/dm/acpi.h
> index b6308b9fa6..a7f8e10ee2 100644
> --- a/include/dm/acpi.h
> +++ b/include/dm/acpi.h
> @@ -27,6 +27,8 @@
>
>  #if !defined(__ACPI__)
>
> +struct nhlt;
> +
>  /** enum acpi_dump_option - selects what ACPI information to dump */
>  enum acpi_dump_option {
> ACPI_DUMP_LIST, /* Just the list of items */
> @@ -44,6 +46,9 @@ enum acpi_dump_option {
>   * adding a new table. The RSDP holds pointers to the RSDT and XSDT.
>   * @rsdt: Pointer to the Root System Description Table
>   * @xsdt: Pointer to the Extended System Description Table
> + * @nhlt: Intel Non-High-Definition-Audio Link Table (NHLT) pointer, used to
> + * build up information that audio codecs need to provide in the NHLT 
> ACPI
> + * table
>   * @len_stack: Stack of 'length' words to fix up later
>   * @ltop: Points to current top of stack (0 = empty)
>   */
> @@ -53,6 +58,7 @@ struct acpi_ctx {
> struct acpi_rsdp *rsdp;
> struct acpi_rsdt *rsdt;
> struct acpi_xsdt *xsdt;
> +   struct nhlt *nhlt;
> char *len_stack[ACPIGEN_LENSTACK_SIZE];
> int ltop;
>  };
> @@ -106,6 +112,15 @@ struct acpi_ops {
>  * @return 0 if OK, -ve on error
>  */
> int (*inject_dsdt)(const struct udevice *dev, struct acpi_ctx *ctx);
> +
> +   /**
> +* setup_nhlt() - Set up audio information for this device
> +*
> +* The method can add information to ctx->nhlt if it likes
> +*
> +* @return 0 if OK, -ENODATA if nothing to add, -ve on error
> +*/
> +   int (*setup_nhlt)(const struct udevice *dev, struct acpi_ctx *ctx);
>  };
>
>  #define device_get_acpi_ops(dev)   ((dev)->driver->acpi_ops)
> @@ -170,6 +185,17 @@ int acpi_fill_ssdt(struct acpi_ctx *ctx);
>   */
>  int acpi_inject_dsdt(struct acpi_ctx *ctx);
>
> +/**
> + * acpi_setup_nhlt() - Set up audio information
> + *
> + * This is called to set up the nhlt information for all devices.
> + *
> + * @ctx: ACPI context to use
> + * @nhlt: Pointer to nhlt information to add to
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_setup_nhlt(struct acpi_ctx *ctx, struct nhlt *nhlt);
> +
>  /**
>   * acpi_dump_items() - Dump out the collected ACPI items
>   *
> --

Regards,
Bin


Re: [PATCH v1 06/43] dm: core: Add a way of overriding the ACPI device path

2020-06-29 Thread Bin Meng
On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> Some devices such as GPIO need to override the normal path that would be
> generated by driver model. Add a device-tree property for this.
>
> Signed-off-by: Simon Glass 
> ---
>
>  doc/device-tree-bindings/device.txt | 23 +++
>  drivers/core/acpi.c | 19 +++
>  include/dm/acpi.h   | 13 +
>  3 files changed, 55 insertions(+)
>

Reviewed-by: Bin Meng 


Re: [PATCH 1/1] riscv: use log functions in fdt_fixup

2020-06-29 Thread Rick Chen
Hi Heinrich

> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> Sent: Friday, June 26, 2020 12:35 PM
> To: Rick Jian-Zhi Chen(陳建志)
> Cc: Bin Meng; Atish Patra; Simon Glass; u-boot@lists.denx.de; Heinrich 
> Schuchardt
> Subject: [PATCH 1/1] riscv: use log functions in fdt_fixup
>
> Replace printf() and debug() by log_err() and log_debug().
>
> "No reserved memory region found in source FDT\n" is not an error but a debug 
> information.
>
> %s/can not/cannot/ - use the more common spelling.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/lib/fdt_fixup.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>

Reviewed-by: Rick Chen 

This patch conflicts with Atish's [PATCH v3 0/2] Assorted fixes
related to reserved memory
Can you rebase it and send again ?

Thanks,
Rick

> diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c index 
> 6db48ad04a..c1dc247cf7 100644
> --- a/arch/riscv/lib/fdt_fixup.c
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -37,7 +37,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
>
> offset = fdt_path_offset(src, "/reserved-memory");
> if (offset < 0) {
> -   printf("No reserved memory region found in source FDT\n");
> +   log_debug("No reserved memory region found in source FDT\n");
> return 0;
> }
>
> @@ -48,7 +48,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
>   "reg", 0, ,
>   false);
> if (addr == FDT_ADDR_T_NONE) {
> -   debug("failed to read address/size for %s\n", name);
> +   log_debug("failed to read address/size for %s\n", 
> name);
> continue;
> }
> strncpy(basename, name, max_len);
> @@ -63,7 +63,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
> err = fdtdec_add_reserved_memory(dst, basename, _mem,
>  );
> if (err < 0) {
> -   printf("failed to add reserved memory: %d\n", err);
> +   log_err("failed to add reserved memory: %d\n", err);
> return err;
> }
> if (!fdt_getprop(src, node, "no-map", NULL)) @@ -109,7 +109,7 
> @@ int board_fix_fdt(void *fdt)
>
> err = riscv_board_reserved_mem_fixup(fdt);
> if (err < 0) {
> -   printf("failed to fixup DT for reserved memory: %d\n", err);
> +   log_err("failed to fixup DT for reserved memory: %d\n", err);
> return err;
> }
>
> @@ -127,14 +127,14 @@ int arch_fixup_fdt(void *blob)
> size = fdt_totalsize(blob);
> err  = fdt_open_into(blob, blob, size + 32);
> if (err < 0) {
> -   printf("Device Tree can't be expanded to accommodate new 
> node");
> +   log_err("Device Tree can't be expanded to accommodate new 
> node");
> return err;
> }
> chosen_offset = fdt_path_offset(blob, "/chosen");
> if (chosen_offset < 0) {
> err = fdt_add_subnode(blob, 0, "chosen");
> if (err < 0) {
> -   printf("chosen node can not be added\n");
> +   log_err("chosen node cannot be added\n");
> return err;
> }
> }
> --
> 2.27.0


Re: [PATCH v1 04/43] acpi: Allow creating the GNVS to fail

2020-06-29 Thread Bin Meng
On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> In some cases an internal error may prevent this from working. Update the
> function return value and report the error. At present the API for writing
> tables does not easily support reporting errors, but once it is fully
> updated to use a context pointer, this will be easier.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v1:
> - Add linux/err.h header
>
>  arch/x86/cpu/baytrail/acpi.c  |  4 +++-
>  arch/x86/cpu/quark/acpi.c |  4 +++-
>  arch/x86/cpu/tangier/acpi.c   |  4 +++-
>  arch/x86/include/asm/acpi_table.h | 10 +-
>  arch/x86/lib/acpi_table.c | 11 +--
>  5 files changed, 27 insertions(+), 6 deletions(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v1 02/43] binman: Refactor binman_entry_find() to allow other nodes

2020-06-29 Thread Bin Meng
Hi Simon,

On Mon, Jun 15, 2020 at 11:57 AM Simon Glass  wrote:
>
> At present we can only read from a top-level binman node entry. Refactor
> this function to produce a second local function which supports reading
> from any node.
>
> Signed-off-by: Simon Glass 
> ---
>
>  lib/binman.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/lib/binman.c b/lib/binman.c
> index dc3a880882..79d01230dd 100644
> --- a/lib/binman.c
> +++ b/lib/binman.c
> @@ -29,25 +29,31 @@ struct binman_info {
>
>  static struct binman_info *binman;
>
> -int binman_entry_find(const char *name, struct binman_entry *entry)
> +int binman_entry_find_(ofnode node, const char *name, struct binman_entry 
> *entry)

This one should be static. We really should agree on a naming
convention for such internal APIs. I would prefer adding _internal
suffix, or using __ prefix

>  {
> -   ofnode node;
> int ret;
>
> -   node = ofnode_find_subnode(binman->image, name);
> if (!ofnode_valid(node))
> -   return log_msg_ret("no binman node", -ENOENT);
> +   node = binman->image;
> +   node = ofnode_find_subnode(node, name);
> +   if (!ofnode_valid(node))
> +   return log_msg_ret("node", -ENOENT);
>
> ret = ofnode_read_u32(node, "image-pos", >image_pos);
> if (ret)
> -   return log_msg_ret("bad binman node1", ret);
> +   return log_msg_ret("import-pos", ret);
> ret = ofnode_read_u32(node, "size", >size);
> if (ret)
> -   return log_msg_ret("bad binman node2", ret);
> +   return log_msg_ret("size", ret);
>
> return 0;
>  }
>
> +int binman_entry_find(const char *name, struct binman_entry *entry)
> +{
> +   return binman_entry_find_(binman->image, name, entry);
> +}
> +
>  void binman_set_rom_offset(int rom_offset)
>  {
> binman->rom_offset = rom_offset;
> --

Regards,
Bin


Re: [PULL] u-boot-mips

2020-06-29 Thread Tom Rini
On Tue, Jun 30, 2020 at 01:10:53AM +0200, Daniel Schwierzeck wrote:

> Hi Tom,
> 
> actually I wanted to send this much earlier but I hope it's still okay.
> 
> This enables Qemu tests for the MIPS Malta board in all variants (32/64 bit,
> big/little endian) in Gitlab CI, Travis CI and Azure Pipelines. This allows
> to deprecate the qemu_mips board in the future because there is no Linux 
> support
> anymore for ages and Qemu deprecated the generic MIPS board as well in favour 
> of
> Malta.
> 
> I had to include the PCNET patches because otherwise the Malta 64bit targets
> had stability issues in the Qemu network test case. Thus it's not just cleanup
> and DM conversion, but also bugfixing ;)
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-mips/pipelines/3824
> https://travis-ci.org/github/danielschwierzeck/u-boot/builds/703302746
> https://dev.azure.com/danielschwierzeck/u-boot/_build/results?buildId=8=results

Is it OK for this to go in to -next at this point?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH] ARM: da850-evm: Unify config options with Kconfig

2020-06-29 Thread Adam Ford
There are two options that are currently whitelisted, but they
are redundant, because there are not necessary since Kconfig options
exist to basically state the same thing.

CONFIG_DIRECT_NOR_BOOT and CONFIG_USE_NOR are both set together and
only used by the da850 when booting from NOR, however the only time
CONFIG_MTD_NOR_FLASH is configured is when booting from NOR. Since
NOR doesn't need SPL, the options for SPL can be moved to a check for
building SPL instead of checking for NOR.

This patch removes the checks for these two config options and unifies
the checks around the Kconfig option of CONFIG_MTD_NOR_FLASH.

Since this board is the only board that uses these two config options,
they can be removed from the whitelist table.

Signed-off-by: Adam Ford 

diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index a3b0f8bf09..c91aeb8dbf 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -205,7 +205,7 @@ int misc_init_r(void)
 }
 
 static const struct pinmux_config gpio_pins[] = {
-#ifdef CONFIG_USE_NOR
+#ifdef CONFIG_MTD_NOR_FLASH
/* GP0[11] is required for NOR to work on Rev 3 EVMs */
{ pinmux(0), 8, 4 },/* GP0[11] */
 #endif
@@ -235,7 +235,7 @@ const struct pinmux_resource pinmuxes[] = {
PINMUX_ITEM(emifa_pins_cs3),
PINMUX_ITEM(emifa_pins_cs4),
PINMUX_ITEM(emifa_pins_nand),
-#elif defined(CONFIG_USE_NOR)
+#elif defined(CONFIG_MTD_NOR_FLASH)
PINMUX_ITEM(emifa_pins_cs2),
PINMUX_ITEM(emifa_pins_nor),
 #endif
@@ -341,7 +341,7 @@ int board_init(void)
 DAVINCI_SYSCFG_SUSPSRC_UART2),
   _syscfg_regs->suspsrc);
 
-#ifdef CONFIG_USE_NOR
+#ifdef CONFIG_MTD_NOR_FLASH
/* Set the GPIO direction as output */
clrbits_le32((u32 *)GPIO_BANK0_REG_DIR_ADDR, (0x01 << 11));
 
diff --git a/configs/da850evm_direct_nor_defconfig 
b/configs/da850evm_direct_nor_defconfig
index ab86108d66..b46ab3c2cf 100644
--- a/configs/da850evm_direct_nor_defconfig
+++ b/configs/da850evm_direct_nor_defconfig
@@ -10,7 +10,6 @@ CONFIG_ENV_SIZE=0x2800
 CONFIG_ENV_SECT_SIZE=0x2
 CONFIG_DM_GPIO=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_SYS_EXTRA_OPTIONS="USE_NOR,DIRECT_NOR_BOOT"
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="mem=32M console=ttyS2,115200n8 root=/dev/mtdblock2 rw 
noinitrd ip=dhcp"
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 4d651264dd..c825a0440b 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -13,10 +13,6 @@
 /*
  * Board
  */
-/* check if direct NOR boot config is used */
-#ifndef CONFIG_DIRECT_NOR_BOOT
-#define CONFIG_USE_SPIFLASH
-#endif
 
 /*
  * SoC Configuration
@@ -28,7 +24,7 @@
 #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
 #define CONFIG_SKIP_LOWLEVEL_INIT_ONLY
 
-#ifdef CONFIG_DIRECT_NOR_BOOT
+#ifdef CONFIG_MTD_NOR_FLASH
 #define CONFIG_SYS_DV_NOR_BOOT_CFG (0x11)
 #endif
 
@@ -107,10 +103,6 @@
 
 #define CONFIG_SYS_SPI_CLK clk_get(DAVINCI_SPI1_CLKID)
 
-#ifdef CONFIG_USE_SPIFLASH
-#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x4
-#endif
-
 /*
  * I2C Configuration
  */
@@ -171,7 +163,7 @@
 #define CONFIG_NET_RETRY_COUNT 10
 #endif
 
-#ifdef CONFIG_USE_NOR
+#ifdef CONFIG_MTD_NOR_FLASH
 #define CONFIG_SYS_MAX_FLASH_BANKS 1 /* max number of flash banks */
 #define CONFIG_SYS_FLASH_SECT_SZ   (128 << 10) /* 128KB */
 #define CONFIG_SYS_FLASH_BASE  DAVINCI_ASYNC_EMIF_DATA_CE2_BASE
@@ -224,16 +216,11 @@
 #define CONFIG_CLOCKS
 #endif
 
-#if !defined(CONFIG_MTD_RAW_NAND) && \
-   !defined(CONFIG_USE_NOR) && \
-   !defined(CONFIG_USE_SPIFLASH)
-#endif
-
 /* USB Configs */
 #define CONFIG_USB_OHCI_NEW
 #define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 15
 
-#ifndef CONFIG_DIRECT_NOR_BOOT
+#ifdef CONFIG_SPL_BUILD
 /* defines for SPL */
 #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_TEXT_BASE - \
CONFIG_SYS_MALLOC_LEN)
@@ -248,12 +235,12 @@
 /* additions for new relocation code, must added to all boards */
 #define CONFIG_SYS_SDRAM_BASE  0xc000
 
-#ifdef CONFIG_DIRECT_NOR_BOOT
+#ifdef CONFIG_MTD_NOR_FLASH
 #define CONFIG_SYS_INIT_SP_ADDR0x8001ff00
 #else
 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000 
- /* Fix this */ \
GENERATED_GBL_DATA_SIZE)
-#endif /* CONFIG_DIRECT_NOR_BOOT */
+#endif /* CONFIG_MTD_NOR_FLASH */
 
 #include 
 
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 916768f361..770bcaf223 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -313,7 +313,6 @@ CONFIG_DFU_ENV_SETTINGS
 CONFIG_DHCP_MIN_EXT_LEN
 CONFIG_DIALOG_POWER
 CONFIG_DIMM_SLOTS_PER_CTLR
-CONFIG_DIRECT_NOR_BOOT
 CONFIG_DISCONTIGMEM
 CONFIG_DISCOVER_PHY
 CONFIG_DISPLAY_AER_
@@ -4161,7 +4160,6 @@ CONFIG_USB_XHCI_EXYNOS
 CONFIG_USB_XHCI_OMAP
 

[PATCH] README: davinci: Clarify when SPL is used and the target devices.

2020-06-29 Thread Adam Ford
The documentation states that SPL is enabled in all config options
for the da850.  This incorrect, because devices booting from NOR
do not need the SPL to do the low level initializion because when
booting from NOR, the board is able to execute in place (XIP)

This also clarifies that SPL isn't only used for booting from SPI,
because it is also used for booting from MMC and NAND for those
devices supporting those boot options.

Signed-off-by: Adam Ford 

diff --git a/doc/README.davinci b/doc/README.davinci
index 6522c24eea..607531af2a 100644
--- a/doc/README.davinci
+++ b/doc/README.davinci
@@ -37,11 +37,15 @@ Bootloaders
 ===
 
 For DA850 an SPL (secondary program loader, see doc/README.SPL) is provided
-to load U-Boot directly from SPI flash. The SPL takes care of the low level
+to load U-Boot from SPI flash, MMC or NAND. The SPL takes care of the low level
 initialization.
 
-The SPL is built as u-boot.ais for all DA850 defconfigs. The resulting
-image file can be programmed to the SPI flash of the DA850 EVM/LCDK.
+The SPL is built as u-boot.ais for all DA850 defconfigs except those booting
+from NOR flash. The resulting image file can be programmed to the SPI flash
+of the DA850 EVM/LCDK.
+
+Devices that support booting from NOR utilize execute in place (XIP) and do
+not require SPL to perform low level initialization.
 
 Environment Variables
 =
-- 
2.25.1



[PULL] u-boot-mips

2020-06-29 Thread Daniel Schwierzeck
Hi Tom,

actually I wanted to send this much earlier but I hope it's still okay.

This enables Qemu tests for the MIPS Malta board in all variants (32/64 bit,
big/little endian) in Gitlab CI, Travis CI and Azure Pipelines. This allows
to deprecate the qemu_mips board in the future because there is no Linux support
anymore for ages and Qemu deprecated the generic MIPS board as well in favour of
Malta.

I had to include the PCNET patches because otherwise the Malta 64bit targets
had stability issues in the Qemu network test case. Thus it's not just cleanup
and DM conversion, but also bugfixing ;)

https://gitlab.denx.de/u-boot/custodians/u-boot-mips/pipelines/3824
https://travis-ci.org/github/danielschwierzeck/u-boot/builds/703302746
https://dev.azure.com/danielschwierzeck/u-boot/_build/results?buildId=8=results


The following changes since commit 0b7d95531cf25a7c71bd9855135da5e7098e7b97:

  Merge tag 'rockchip-fix' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-video (2020-06-29 15:58:09 
-0400)

are available in the Git repository at:

  g...@gitlab.denx.de:u-boot/custodians/u-boot-mips.git 
tags/mips-pull-2020-06-29

for you to fetch changes up to e35c2a8fdd41a34c06c409ce700c5d5591429367:

  .azure-pipelines.yml: add Qemu tests for MIPS Malta board (2020-06-29 
22:40:16 +0200)


- net: pcnet: cleanup and add DM support
- Makefile: add rule to build an endian-swapped U-Boot image
  used by MIPS Malta EL variants
- CI: add Qemu tests for MIPS Malta


Daniel Schwierzeck (6):
  tools: add script for byte endianness swapping
  Makefile: add rule to generate u-boot-swap.bin
  mips: malta: build u-boot-swap.bin
  .gitlab-ci.yml: add Qemu tests for MIPS Malta board
  .travis.yml: add Qemu tests for MIPS Malta board
  .azure-pipelines.yml: add Qemu tests for MIPS Malta board

Marek Vasut (15):
  net: pcnet: Drop typedef struct pcnet_priv_t
  net: pcnet: Drop PCNET_HAS_PROM
  net: pcnet: Use PCI_DEVICE() to define PCI device compat list
  net: pcnet: Simplify private data allocation
  net: pcnet: Replace memset+malloc with calloc
  net: pcnet: Move private data allocation to initialize
  net: pcnet: Move initialize function at the end
  net: pcnet: Drop useless forward declarations
  net: pcnet: Wrap devbusfn into private data
  net: pcnet: Pass private data through dev->priv
  net: pcnet: Wrap iobase into private data
  net: pcnet: Wrap name and enetaddr into private data
  net: pcnet: Split common and non-DM functions
  net: pcnet: Add DM support
  net: pcnet: Add Kconfig entries

 .azure-pipelines.yml|  16 ++
 .gitlab-ci.yml  |  32 +++
 .travis.yml |  28 ++
 Makefile|   6 +
 configs/malta64_defconfig   |   1 +
 configs/malta64el_defconfig |   2 +
 configs/malta_defconfig |   1 +
 configs/maltael_defconfig   |   2 +
 drivers/net/Kconfig |   6 +
 drivers/net/pcnet.c | 618 +++-
 include/configs/malta.h |   2 -
 tools/endian-swap.py|  55 
 12 files changed, 525 insertions(+), 244 deletions(-)
 create mode 100755 tools/endian-swap.py


[PATCH v2] cmd: add a panic command

2020-06-29 Thread Heiko Stuebner
From: Heiko Stuebner 

Even in boot scripts it may be needed to "panic" when all options
are exhausted and the device specification specifies hanging
instead of resetting the board.

So add a new panic command that just wraps around the core panic
call in U-Boot and can take an optional message.

Signed-off-by: Heiko Stuebner 
Reviewed-by: Simon Glass 
---
changes in v2:
- add blank line before return (Simon)
- fix U-Boot spelling (Simon)

 cmd/Makefile |  1 +
 cmd/panic.c  | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 cmd/panic.c

diff --git a/cmd/Makefile b/cmd/Makefile
index ac843b4b16..027fa9083a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -8,6 +8,7 @@ ifndef CONFIG_SPL_BUILD
 obj-y += boot.o
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
 obj-y += help.o
+obj-y += panic.o
 obj-y += version.o
 
 # command
diff --git a/cmd/panic.c b/cmd/panic.c
new file mode 100644
index 00..329231fb66
--- /dev/null
+++ b/cmd/panic.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include 
+#include 
+
+static int do_panic(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[])
+{
+   char *text = (argc < 2) ? "" : argv[1];
+
+   panic(text);
+
+   return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+   panic,  2,  1,  do_panic,
+   "Panic with optional message",
+   "[message]"
+);
-- 
2.26.2



Re: [PATCH v3 2/4] mips: octeon: Initial minimal support for the Marvell Octeon SoC

2020-06-29 Thread Daniel Schwierzeck
Am Freitag, den 19.06.2020, 15:44 +0200 schrieb Stefan Roese:
> From: Aaron Williams 
> 
> This patch adds very basic support for the Octeon III SoCs. Only
> CFI parallel NOR flash and UART is supported for now.
> 
> Please note that the basic Octeon port does not include the DDR3/4
> initialization yet. This will be added in some follow-up patches
> later. To still use U-Boot on with this port, the L2 cache (4MiB on
> Octeon III CN73xx) is used as RAM. This way, U-Boot can boot to the
> prompt on such boards.
> 
> Signed-off-by: Aaron Williams 
> Signed-off-by: Stefan Roese 
> 
> ---
> 
> Changes in v3:
> - Don't "relocate" to L2 cache for now
> - Remove inclusion of "common.h"
> 
> Changes in v2:
> - Remove custom start.S and use common start.S. Minimal custom lowlevel
>   init code is currently added in the custom lowlevel_init.S. This needs
>   to be extended with necessary code, like errata handling etc. But for
>   a very first basic port, this seems to be all thats needed to boot on
>   the EBB7304 to the prompt.
> - Removed select CREATE_ARCH_SYMLINK
> - Removed Octeon II support, as its currently no added in this patchset
> - Added cache.c to add the platform specific cache functions as no-ops
>   for Octeon as the platform is cache coherent
> - Removed CONFIG_MIPS_CACHE_COHERENT
> - Added CONFIG_CPU_CAVIUM_OCTEON to Kconfig and selected it for Octeon
>   to enable better sync with the Linux files in the future
> - Add get_tbclk() -> no need to define CONFIG_SYS_MIPS_TIMER_FREQ any more
> 
>  MAINTAINERS   |  6 ++
>  arch/mips/Kconfig | 41 +
>  arch/mips/Makefile|  3 +
>  arch/mips/mach-octeon/Kconfig | 46 +++
>  arch/mips/mach-octeon/Makefile| 10 
>  arch/mips/mach-octeon/cache.c | 20 +++
>  arch/mips/mach-octeon/clock.c | 27 +
>  arch/mips/mach-octeon/cpu.c   | 57 +++
>  arch/mips/mach-octeon/dram.c  | 28 +
>  arch/mips/mach-octeon/include/ioremap.h   | 30 ++
>  arch/mips/mach-octeon/include/mach/cavm-reg.h | 42 ++
>  arch/mips/mach-octeon/include/mach/clock.h| 22 +++
>  arch/mips/mach-octeon/lowlevel_init.S | 19 +++
>  scripts/config_whitelist.txt  |  1 -
>  14 files changed, 351 insertions(+), 1 deletion(-)
>  create mode 100644 arch/mips/mach-octeon/Kconfig
>  create mode 100644 arch/mips/mach-octeon/Makefile
>  create mode 100644 arch/mips/mach-octeon/cache.c
>  create mode 100644 arch/mips/mach-octeon/clock.c
>  create mode 100644 arch/mips/mach-octeon/cpu.c
>  create mode 100644 arch/mips/mach-octeon/dram.c
>  create mode 100644 arch/mips/mach-octeon/include/ioremap.h
>  create mode 100644 arch/mips/mach-octeon/include/mach/cavm-reg.h
>  create mode 100644 arch/mips/mach-octeon/include/mach/clock.h
>  create mode 100644 arch/mips/mach-octeon/lowlevel_init.S
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1fd975c72f..0aa0357967 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -763,6 +763,12 @@ M:   Ezequiel Garcia 
>  S:   Maintained
>  F:   arch/mips/mach-jz47xx/
>  
> +MIPS Octeon
> +M:   Aaron Williams 
> +S:   Maintained
> +F:   arch/mips/mach-octeon/
> +F:   arch/mips/include/asm/arch-octeon/
> +
>  MMC
>  M:   Peng Fan 
>  S:   Maintained
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index bccd06cb0c..dd56da6dae 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -106,6 +106,23 @@ config ARCH_JZ47XX
>   select OF_CONTROL
>   select DM
>  
> +config ARCH_OCTEON
> + bool "Support Marvell Octeon CN7xxx platforms"
> + select CPU_CAVIUM_OCTEON
> + select DISPLAY_CPUINFO
> + select DMA_ADDR_T_64BIT
> + select DM
> + select DM_SERIAL
> + select MIPS_L2_CACHE
> + select MIPS_TUNE_OCTEON3
> + select ROM_EXCEPTION_VECTORS
> + select SUPPORTS_BIG_ENDIAN
> + select SUPPORTS_CPU_MIPS64_OCTEON
> + select PHYS_64BIT
> + select OF_CONTROL
> + select OF_LIVE
> + imply CMD_DM
> +
>  config MACH_PIC32
>   bool "Support Microchip PIC32"
>   select DM
> @@ -160,6 +177,7 @@ source "arch/mips/mach-bmips/Kconfig"
>  source "arch/mips/mach-jz47xx/Kconfig"
>  source "arch/mips/mach-pic32/Kconfig"
>  source "arch/mips/mach-mtmips/Kconfig"
> +source "arch/mips/mach-octeon/Kconfig"
>  
>  if MIPS
>  
> @@ -233,6 +251,14 @@ config CPU_MIPS64_R6
> Choose this option to build a kernel for release 6 or later of the
> MIPS64 architecture.
>  
> +config CPU_MIPS64_OCTEON
> + bool "Marvell Octeon series of CPUs"
> + depends on SUPPORTS_CPU_MIPS64_OCTEON
> + select 64BIT
> + help
> +  Choose this option for Marvell Octeon CPUs.  These CPUs are between
> +  MIPS64 R5 and R6 with other extensions.
> +
>  endchoice
>  
>  menu "General setup"
> @@ -408,6 +434,12 @@ config 

Re: [PATCH v3 1/4] sysreset: Add Octeon sysreset driver

2020-06-29 Thread Daniel Schwierzeck


> This patch adds a UCLASS_SYSRESET sysreset driver for the Octeon SoC
> family.
> 
> Signed-off-by: Stefan Roese 
> ---
> 
> (no changes since v1)
> 
>  drivers/sysreset/Kconfig   |  7 
>  drivers/sysreset/Makefile  |  1 +
>  drivers/sysreset/sysreset_octeon.c | 52 ++
>  3 files changed, 60 insertions(+)
>  create mode 100644 drivers/sysreset/sysreset_octeon.c
> 
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel



Re: [PATCH v1 2/5] mips: octeon: use mips_mach_early_init() to copy to L2 cache

2020-06-29 Thread Daniel Schwierzeck


> This patch adds the code to copy itself from bootrom location to a
> different location (TEXT_BASE) to the Octeon platform. Its used in
> this case to copy the complete U-Boot image into L2 cache, which
> greatly improves the bootup time - especially in regard to the
> very long and complex DDR4 init code.
> 
> The Kconfig symbol CONFIG_MIPS_MACH_EARLY_INIT is enabled with this
> patch for Octeon.
> 
> Signed-off-by: Stefan Roese 
> ---
> 
>  arch/mips/Kconfig |  1 +
>  arch/mips/mach-octeon/lowlevel_init.S | 56 +++
>  2 files changed, 57 insertions(+)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 327fd4848a..bcf6f26457 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -114,6 +114,7 @@ config ARCH_OCTEON
>   select DM
>   select DM_SERIAL
>   select MIPS_L2_CACHE
> + select MIPS_MACH_EARLY_INIT
>   select MIPS_TUNE_OCTEON3
>   select ROM_EXCEPTION_VECTORS
>   select SUPPORTS_BIG_ENDIAN
> diff --git a/arch/mips/mach-octeon/lowlevel_init.S 
> b/arch/mips/mach-octeon/lowlevel_init.S
> index d9aab38cde..2d9257b1ed 100644
> --- a/arch/mips/mach-octeon/lowlevel_init.S
> +++ b/arch/mips/mach-octeon/lowlevel_init.S
> @@ -17,3 +17,59 @@ LEAF(lowlevel_init)
>   jr  ra
>nop
>   END(lowlevel_init)
> +
> +LEAF(mips_mach_early_init)
> +
> +moves0, ra

indentation

> +
> + bal __dummy
> +  nop
> +
> +__dummy:
> + /* Get the actual address that we are running at */
> + PTR_LA  a6, _start  /* Linked address of _start */
> + PTR_LA  a7, __dummy
> + dsubu   t1, a7, a6  /* offset of __dummy label from _start*/
> + dsubu   t0, ra, t1  /* t0 now has actual address of _start*/

including _start in the calculation makes it a little bit hard to
understand. Wouldn't it be enough to just calculate the difference
between a7 and ra to get the relocation offset? You can use that offset
later to calculate the destination address based on _start.

> +
> + PTR_LI  t1, CONFIG_SYS_TEXT_BASE

isn't that the same address as _start?

> +
> + /* Calculate end address of copy loop */
> + PTR_LI  s5, CONFIG_BOARD_SIZE_LIMIT

couldn't you use __image_copy_end to get the real binary size without
BSS? Or _end if you need to copy the relocation table as well.

> + daddu   t2, s5, t0  /* t2 = end address */
> + daddiu  t2, t2, 127
> + ins t2, zero, 0, 7  /* Round up to cache line for memcpy */
> +
> + /* Copy ourself to the L2 cache from flash, 32 bytes at a time */
> +1:
> + ld  a0, 0(t0)
> + ld  a1, 8(t0)
> + ld  a2, 16(t0)
> + ld  a3, 24(t0)
> + sd  a0, 0(t1)
> + sd  a1, 8(t1)
> + sd  a2, 16(t1)
> + sd  a3, 24(t1)
> + addiu   t0, 32
> + bne t0, t2, 1b
> + addiu   t1, 32

the instruction in the delay slot should be indented by an extra space
character

> +
> + sync
> + synci   0(zero)
> +
> + PTR_LA  t9, uboot_in_cache
> + j   t9
> +  nop

Why the extra jump? If you have the relocation offset as suggested
above, you could simply add that to s0 and do one jr instruction.

Also instead of synci you could use jr.hb to automatically add a
instruction hazard barrier during the jump (if that's implemented on
Octeon).


> +
> +uboot_in_cache:
> +
> + /*
> +  * Return to start.S now running from TEXT_BASE, which points
> +  * to DRAM address space, which effectively is L2 cache now.
> +  * This speeds up the init process extremely, especially the
> +  * DDR init code.
> +  */
> + jr  s0
> +  nop
> +
> + END(mips_mach_early_init)
-- 
- Daniel



Re: [PATCH v1 1/5] mips: Add CONFIG_MIPS_MACH_EARLY_INIT for very early mach init code

2020-06-29 Thread Daniel Schwierzeck


> This patch adds the optional call to mips_mach_early_init() to start.S
> at a very early stage. Its disabled per default. It can be used for
> very early machine / platform specific init code.  Its called very
> early and at this stage the PC is allowed to differ from the linking
> address (CONFIG_TEXT_BASE) as no absolute jump has been performed until
> this call.
> 
> It will be used by thje Octeon platform.
> 
> Signed-off-by: Stefan Roese 
> ---
> 
>  arch/mips/Kconfig | 9 +
>  arch/mips/cpu/start.S | 5 +
>  2 files changed, 14 insertions(+)
> 
> 

Reviewed-by: Daniel Schwierzeck 

-- 
- Daniel



Re: Please pull u-boot-video

2020-06-29 Thread Tom Rini
On Mon, Jun 29, 2020 at 09:50:18PM +0200, Anatolij Gustschin wrote:

> Hi Tom,
> 
> please pull one more bugfix for v2020.07. Thanks!
> 
> The following changes since commit 19a7e5814b77b288472aa96b6d94fb2591cc9184:
> 
>   Merge tag 'fixes-for-v2020.07' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-video (2020-06-28 10:12:25 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-video.git tags/rockchip-fix
> 
> for you to fetch changes up to 35ee34b2c2adc961e1ae4e68c5b7e380d7c448a0:
> 
>   video: rockchip: fix HDMI 4K resolution (2020-06-29 17:53:16 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Please pull u-boot-video

2020-06-29 Thread Anatolij Gustschin
Hi Tom,

please pull one more bugfix for v2020.07. Thanks!

The following changes since commit 19a7e5814b77b288472aa96b6d94fb2591cc9184:

  Merge tag 'fixes-for-v2020.07' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-video (2020-06-28 10:12:25 
-0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-video.git tags/rockchip-fix

for you to fetch changes up to 35ee34b2c2adc961e1ae4e68c5b7e380d7c448a0:

  video: rockchip: fix HDMI 4K resolution (2020-06-29 17:53:16 +0200)


- fix "Synchronous Abort" when using rk3399 4K HDMI


Anatolij Gustschin (1):
  video: rockchip: fix HDMI 4K resolution

 drivers/video/rockchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Re: [PATCH] sunxi: Add support for using UART4 as console on A64

2020-06-29 Thread Nazım Gediz AYDINDOĞMUŞ
Hi.

If I've understood it well, you're pointing out for the following part,
right?

>  /* CPU */
>  #define COUNTER_FREQUENCY2400
> @@ -248,6 +252,8 @@ extern int soft_i2c_gpio_scl;
>  #define OF_STDOUT_PATH   "/soc@01c0/serial@01c28800:115200"
>  #elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I)
>  #define OF_STDOUT_PATH   "/soc@01c0/serial@01f02800:115200"
> +#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I)
> +#define OF_STDOUT_PATH   "/soc@01c0/serial@01c29000:115200"

To be honest, this part was remnant of days long trial and error attempts
at trying to make UART4 work.
Sorry for not scrutinizing it carefully. It was not because do not taking
it serious but due to not fully grasping the said changes.

If there's not any other thing to remove/add/fix, should I reformat and
submit a completely new patch or is it okay to send the updated one as a
follow-up post in this thread?

Thanks for the review, by the way.


On 29.06.2020 18:27, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Jun 29, 2020 at 12:09:38PM +0300, Nazım Gediz Aydındoğmuş wrote:
>> A64 has UART4 but it was in conflict with R_UART of older SoCs (e.g. A23).
>>
>> This commit adds necessary definitions and checks to use UART4 port on A64.
>>
>> Signed-off-by: Nazım Gediz Aydındoğmuş 
>> ---
>>
>>  arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
>>  arch/arm/mach-sunxi/board.c| 4 
>>  arch/arm/mach-sunxi/clock_sun6i.c  | 3 ++-
>>  include/configs/sunxi-common.h | 6 ++
>>  4 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
>> b/arch/arm/include/asm/arch-sunxi/gpio.h
>> index a646ea6a3c..1407aff25f 100644
>> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
>> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
>> @@ -176,6 +176,7 @@ enum sunxi_gpio_number {
>>  #define SUNXI_GPD_LCD0  2
>>  #define SUNXI_GPD_LVDS0 3
>>  #define SUNXI_GPD_PWM   2
>> +#define SUN50I_GPD_UART43
>>  
>>  #define SUN5I_GPE_SDC2  3
>>  #define SUN8I_GPE_TWI2  3
>> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
>> index f40fccd8f8..7d95b7dd29 100644
>> --- a/arch/arm/mach-sunxi/board.c
>> +++ b/arch/arm/mach-sunxi/board.c
>> @@ -140,6 +140,10 @@ static int gpio_init(void)
>>  sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL_R_UART);
>>  sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL_R_UART);
>>  sunxi_gpio_set_pull(SUNXI_GPL(3), SUNXI_GPIO_PULL_UP);
>> +#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I)
>> +sunxi_gpio_set_cfgpin(SUNXI_GPD(2), SUN50I_GPD_UART4);
>> +sunxi_gpio_set_cfgpin(SUNXI_GPD(3), SUN50I_GPD_UART4);
>> +sunxi_gpio_set_pull(SUNXI_GPD(3), SUNXI_GPIO_PULL_UP);
>>  #else
>>  #error Unsupported console port number. Please fix pin mux settings in 
>> board.c
>>  #endif
>> diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
>> b/arch/arm/mach-sunxi/clock_sun6i.c
>> index 8e84062bd7..4bb2d66b1e 100644
>> --- a/arch/arm/mach-sunxi/clock_sun6i.c
>> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
>> @@ -83,7 +83,8 @@ void clock_init_sec(void)
>>  
>>  void clock_init_uart(void)
>>  {
>> -#if CONFIG_CONS_INDEX < 5
>> +#if CONFIG_CONS_INDEX < 5 || \
>> +  defined(CONFIG_MACH_SUN50I) && CONFIG_CONS_INDEX < 6
>>  struct sunxi_ccm_reg *const ccm =
>>  (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
>>  
>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
>> index 5b0bec0561..f7a97b3dec 100644
>> --- a/include/configs/sunxi-common.h
>> +++ b/include/configs/sunxi-common.h
>> @@ -45,8 +45,12 @@
>>  # define CONFIG_SYS_NS16550_COM2SUNXI_UART1_BASE
>>  # define CONFIG_SYS_NS16550_COM3SUNXI_UART2_BASE
>>  # define CONFIG_SYS_NS16550_COM4SUNXI_UART3_BASE
>> +#if defined(CONFIG_MACH_SUN50I)
>> +# define CONFIG_SYS_NS16550_COM5SUNXI_UART4_BASE
>> +#else
>>  # define CONFIG_SYS_NS16550_COM5SUNXI_R_UART_BASE
>>  #endif
>> +#endif
>>  
>>  /* CPU */
>>  #define COUNTER_FREQUENCY   2400
>> @@ -248,6 +252,8 @@ extern int soft_i2c_gpio_scl;
>>  #define OF_STDOUT_PATH  "/soc@01c0/serial@01c28800:115200"
>>  #elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I)
>>  #define OF_STDOUT_PATH  "/soc@01c0/serial@01f02800:115200"
>> +#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I)
>> +#define OF_STDOUT_PATH  "/soc@01c0/serial@01c29000:115200"
> 
> The soc node doesn't have a unit-address on the A64
> Maxime
> 



Re: [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware

2020-06-29 Thread Jan Kiszka

On 29.06.20 14:37, Tom Rini wrote:

On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote:

+Tom

On 23/06/20 8:11 pm, Jan Kiszka wrote:

On 23.06.20 14:37, Jan Kiszka wrote:

On 23.06.20 13:50, Lokesh Vutla wrote:



On 23/06/20 4:45 pm, Jan Kiszka wrote:

From: Jan Kiszka 

To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. The firmware itself is
embedded into U-Boot binary.

One possible firmware source is https://github.com/siemens/k3-rti-wdt.

Signed-off-by: Jan Kiszka 
---
   drivers/watchdog/Kconfig  | 20 
   drivers/watchdog/Makefile |  3 +++
   drivers/watchdog/rti_wdt.c    | 24 
   drivers/watchdog/rti_wdt_fw.S | 20 
   4 files changed, 67 insertions(+)
   create mode 100644 drivers/watchdog/rti_wdt_fw.S

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ee99bd2af1..fd6ab9a85b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -162,6 +162,26 @@ config WDT_K3_RTI
     Say Y here if you want to include support for the K3 watchdog
     timer (RTI module) available in the K3 generation of processors.
+if WDT_K3_RTI
+
+config WDT_K3_RTI_LOAD_FW
+    bool "Load watchdog firmware"
+    depends on REMOTEPROC
+    help
+  Automatically load the specified firmware image into the MCU R5F
+  core 0. On the AM65x, this firmware is supposed to handle the expiry
+  of the watchdog timer, typically by resetting the system.
+
+config WDT_K3_RTI_FW_FILE
+    string "Watchdog firmware image file"
+    default "k3-rti-wdt.fw"
+    depends on WDT_K3_RTI_LOAD_FW
+    help
+  Firmware image to be embedded into U-Boot and loaded on watchdog
+  start.
+
+endif
+
   config WDT_SANDBOX
   bool "Enable Watchdog Timer support for Sandbox"
   depends on SANDBOX && WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 16bdbf4970..bf58684875 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
   obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
   obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
   obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
+obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o
   obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
   obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
   obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
   obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
+
+$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE
diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
index ebe29c7409..38e82a6b6b 100644
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -14,6 +14,7 @@
   #include 
   #include 
   #include 
+#include 
   /* Timer register set definition */
   #define RTIDWDCTRL    0x90
@@ -37,11 +38,16 @@
   #define WDT_PRELOAD_MAX    0xfff
+#define RTI_PROC_ID    0


Can we get the rproc id from DT?


You mean, resolve "mcu_r5fss0_core0" to the ID? Doable.



I'm now probing for the first instance of "ti,am654-r5f" compatible. That
excludes usage for the J721E for now, but that one is fine without firmware -
provided there is way to prevent power-down for RTI watchdog otherwise...


I was more of thinking to have a DT property to reference R5-core. But anyways,
the property is not present in kernel. I am okay with this for now.


Note that not all properties in a DT in Linux need to be used in Linux,
this is something I _think_ there is growing understanding of.


+
   struct rti_wdt_priv {
   phys_addr_t regs;
   unsigned int clk_khz;
   };
+extern const u32 rti_wdt_fw[];
+extern const int rti_wdt_fw_size;


FIT is the preferred way of packing images in U-Boot. Can you try using it?


How does that work? Some example for me?



If you happen to refer to fs-loader: That does not target OSPI, our primary use
case.


No. I was thinking to pack the image in FIT along with ATF and OPTEE like in
k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the
firmware.




What benefit would that bring? There are other users of this pattern, e.g.
board/xilinx/zynqmp/pm_cfg_obj.S.


I didn't know U-Boot is accepting this. Tom, is this the preferred way for
including firmware images?


Adding in Michal.  Why is this area doing what it's doing and not one of
the other generic ways to handle this problem?  Thanks!



So, what are the recommended "generic ways" for these use cases?

Is there a way to stick own stuff into u-boot.itb and get that provided 
to some handler of U-Boot proper? Seems unlikely. The pattern I found 
pushes the firmware into the kernel fit image - which is a clear no-go 
for the watchdog use case because it shall monitor the booting of that 
very same image (software update case).


Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence 

[PATCH v2 1/1] fs: error handling in do_load()

2020-06-29 Thread Heinrich Schuchardt
If a file cannot be loaded, show an error message.
Set the EFI boot device only after successfully loading a file.

Signed-off-by: Heinrich Schuchardt 
---
v2:
use if() instead of #ifdef
---
 fs/fs.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/fs/fs.c b/fs/fs.c
index ad4caaeb1e..7268ec87aa 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -715,15 +715,17 @@ int do_load(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[],
else
pos = 0;

-#ifdef CONFIG_CMD_BOOTEFI
-   efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
-   (argc > 4) ? argv[4] : "");
-#endif
time = get_timer(0);
ret = _fs_read(filename, addr, pos, bytes, 1, _read);
time = get_timer(time);
-   if (ret < 0)
+   if (ret < 0) {
+   printf("Failed to load '%s'\n", filename);
return 1;
+   }
+
+   if (IS_ENABLED(CONFIG_CMD_BOOTEFI))
+   efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
+   (argc > 4) ? argv[4] : "");

printf("%llu bytes read in %lu ms", len_read, time);
if (time > 0) {
--
2.27.0



[PATCH v3 14/14] arm: add (default) config for nanopi2 board

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- Configuration changed, mainly several "CONFIG_..." moved from
  s5p4418_nanopi2.h to s5p4418_nanopi2_defconfig and USB related
  configs removed because USB is not supported yet.
- s5p4418_nanopi2.h: "CONFIG_" removed from several s5p4418/nanopi2
  specific defines because the appropriate values do not need to be
  configurable.
- pinctrl is supported now, therefore "CONFIG_PINCTRL=y" added to
  s5p4418_nanopi2_defconfig.


Signed-off-by: Stefan Bosch 
---

Changes in v3:
- CONFIG_SYS_RESERVE_MEM_SIZE removed, has not been used anymore
- s5p4418_nanopi2_defconfig: "CONFIG_PINCTRL=y" added because pinctrl
  is supported now. "CONFIG_EFI_LOADER=n" removed (there have been
  boot errors "efi_runtime_relocate: Unknown relocation type 0" at a
  previous U-Boot Version without this). "CONFIG_DM_I2C_GPIO=y" removed
  because I2C-peripherial is used (Nexell I2C driver). Some configs
  moved down for cosmetic reason.
- Handling of Configs for LCD backlight control reworked because (among
  others) not setting CONFIG_S5P4418_ONEWIRE and/or CONFIG_PWM_NX has
  caused errors when compiling board/friendlyarm/nanopi2/onewire.c.
- CONFIG_SYS_MEMTEST_START, CONFIG_SYS_MEMTEST_END, CONFIG_CMDLINE_TAG
  and CONFIG_CMD_BMP moved from s5p4418_nanopi2.h to
  s5p4418_nanopi2_defconfig.
- "#undef CONFIG_CMD_IMLS" removed in s5p4418_nanopi2.h

Changes in v2:
- USB related configs removed because USB is not supported yet.
- CONFIG_CMD_MEMTEST moved from s5p4418_nanopi2.h to
  s5p4418_nanopi2_defconfig.
- MAINTAINERS: "F: drivers/pwm/pwm-nexell*" deleted because
  arch/arm/cpu/armv7/s5p-common/pwm.c is used now. Furthermore double
  line "F: drivers/video/nexell/" deleted.

 MAINTAINERS   |  17 +++
 configs/s5p4418_nanopi2_defconfig | 147 ++
 doc/README.s5p4418|  63 ++
 include/configs/s5p4418_nanopi2.h | 257 ++
 4 files changed, 484 insertions(+)
 create mode 100644 configs/s5p4418_nanopi2_defconfig
 create mode 100644 doc/README.s5p4418
 create mode 100644 include/configs/s5p4418_nanopi2.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1fd975c..314162c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -270,6 +270,23 @@ F: arch/arm/mach-at91/
 F: board/atmel/
 F: drivers/misc/microchip_flexcom.c
 
+ARM NEXELL S5P4418
+M: Stefan Bosch 
+S: Maintained
+F: arch/arm/cpu/armv7/s5p4418/
+F: arch/arm/dts/s5p4418*
+F: arch/arm/mach-nexell/
+F: board/friendlyarm/
+F: configs/s5p4418_nanopi2_defconfig
+F: doc/README.s5p4418
+F: drivers/gpio/nx_gpio.c
+F: drivers/i2c/nx_i2c.c
+F: drivers/mmc/nexell_dw_mmc_dm.c
+F: drivers/pinctrl/nexell/
+F: drivers/video/nexell/
+F: drivers/video/nexell_display.c
+F: include/configs/s5p4418_nanopi2.h
+
 ARM OWL
 M: Manivannan Sadhasivam 
 S: Maintained
diff --git a/configs/s5p4418_nanopi2_defconfig 
b/configs/s5p4418_nanopi2_defconfig
new file mode 100644
index 000..c1cd08a
--- /dev/null
+++ b/configs/s5p4418_nanopi2_defconfig
@@ -0,0 +1,147 @@
+CONFIG_ARM=y
+CONFIG_ARCH_NEXELL=y
+CONFIG_ARCH_S5P4418=y
+CONFIG_TARGET_NANOPI2=y
+CONFIG_DEFAULT_DEVICE_TREE="s5p4418-nanopi2"
+CONFIG_FIT=y
+
+CONFIG_SYS_MEMTEST_START=0x7100
+CONFIG_SYS_MEMTEST_END=0xb000
+
+CONFIG_CMD_MEMTEST=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_I2C=y
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+# CONFIG_CMD_NET is not set
+
+# Default is CONFIG_NET=y, in this case:
+#   Loading Environment from MMC... ## Warning: Unknown environment variable 
type 'm'
+#   OK
+# CONFIG_CMD_NET=y must be set to avoid this Warning. But then:
+#   Net:   Net Initialization Skipped
+#   No ethernet found.
+# If CONFIG_NET=n is set additionally warning at "make 
s5p4418_nanopi2_defconfig":
+#arch/../configs/s5p4418_nanopi2_defconfig:24:warning: override: 
reassigning to symbol CMD_NET
+#
+# --> CONFIG_NET=n set only
+CONFIG_NET=n
+
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_FDISK=y
+CONFIG_CMD_EXT4_IMG_WRITE=y
+CONFIG_CMD_SD_RECOVERY=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+
+CONFIG_PINCTRL=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_NEXELL=y
+CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_AXP228=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_AXP228=y
+CONFIG_DM_PWM=n
+
+CONFIG_DISPLAY=y
+CONFIG_DM_VIDEO=y
+CONFIG_SYS_CONSOLE_BG_COL=0xff
+CONFIG_SYS_CONSOLE_FG_COL=0x00
+CONFIG_VIDEO_NX=y
+CONFIG_VIDEO_NX_RGB=y
+CONFIG_VIDEO_NX_LVDS=y
+CONFIG_VIDEO_NX_HDMI=y
+CONFIG_CMD_BMP=y
+
+## LCD backlight control
+CONFIG_S5P4418_ONEWIRE=y
+CONFIG_PWM_NX is not set
+
+CONFIG_REGEX=y
+CONFIG_ERRNO_STR=y
+
+CONFIG_SYS_TEXT_BASE=0x74C0
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SYS_CACHELINE_SIZE=64
+
+## System initialize options (board_init_f)
+# board_init_f->init_sequence, call board_early_init_f
+CONFIG_BOARD_LATE_INIT=y
+# board_init_f->init_sequence, call 

[PATCH v3 13/14] arm: add support for SoC s5p4418 (cpu) / nanopi2 board

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- SPL not supported yet --> no spl-dir in arch/arm/cpu/armv7/s5p4418/.
  Appropriate line in Makefile removed.
- cpu.c: '#include ' added.
- arch/arm/cpu/armv7/s5p4418/u-boot.lds removed, is not required
  anylonger.
- "obj-$(CONFIG_ARCH_NEXELL) += s5p-common/" added to
  arch/arm/cpu/armv7/Makefile since s5p-common/pwm.c is used instead
  of drivers/pwm/pwm-nexell.c.
- s5p4418.dtsi: '#include "../../../include/generated/autoconf.h"'
  removed, is not necessary, error at out-of-tree building.
  '#ifdef CONFIG_CPU_NXP4330'-blocks (2x) removed. Some minor changes
  regarding mmc. 'u-boot,dm-pre-reloc' added to dp0 because of added
  DM_VIDEO support.
- board/s5p4418/ renamed to board/friendlyarm/
- All s5p4418-boards except nanopi2 removed because there is no
  possibility to test the other boards.
- Kconfig: Changes to have a structure like mach-bcm283x (RaspberryPi),
  e.g. "config ..." entries moved from/to other Kconfig.
- "CONFIG_" removed from several s5p4418/nanopi2 specific defines
  because the appropriate values do not need to be configurable.
- nanopi2/board.c: All getenv(), getenv_ulong(), setenv() and saveenv()
  renamed to env_get(), env_get_ulong(), env_set() and env_save(),
  respectively. MACH_TYPE_S5P4418 is not defined anymore, therefore
  appropriate code removed (not necessary for DT-kernels).
- nanopi2/onewire.c: All crc8() renamed to crc8_ow() because crc8() is
  already defined in lib/crc8.c (with different parameters).
- dts: "nexell,s5pxx18-i2c" used instead of "i2c-gpio", i2c0 and
  i2c1 added. gmac-, ehci- and dwc2otg-entries removed because the
  appropriate functionality is not supported yet. New mmc-property
  "mmcboost" added.
  s5p4418-pinctrl.dtsi: gmac-entries removed, mmc- and i2c-entries
  added.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
  possible (and similar).

Signed-off-by: Stefan Bosch 
---

Changes in v3:
- dts: pinctrl is supported now, therefore s5p4418-pinctrl.dtsi added,
  mmc- and i2c-entries extended appropriately. New mmc-property
  "mmcboost" added.
- Handling of Configs for LCD backlight control reworked because (among
  others) not setting CONFIG_S5P4418_ONEWIRE and/or CONFIG_PWM_NX has
  caused errors when compiling board/friendlyarm/nanopi2/onewire.c.
- arch/arm/cpu/armv7/s5p4418/cpu.c: '#include ' inserted
  because it has been removed from common.h.
- board/friendlyarm/nanopi2/board.c: Several includes inserted because
  some includes have been removed from common.h.
- '#ifdef...' changed to 'if (IS_ENABLED(CONFIG...))' where possible
  because of appropriate warnings of patman.
- Several initialisations of static variables to 0 removed because of
  appropriate errors of patman.

Changes in v2:
- i2c: "nexell,s5pxx18-i2c"-driver is used now instead of "i2c-gpio".
  i2c0 and i2c1 added. I.e. dts files changed appropriately.
- dts: gmac-, ehci- and dwc2otg-entries removed because the appropriate
  functionality is not supported yet.
- s5p4418-pinctrl.dtsi removed because there is no pinctrl-driver
  available.
- "obj-$(CONFIG_ARCH_NEXELL) += s5p-common/" added to
  arch/arm/cpu/armv7/Makefile since s5p-common/pwm.c is used now instead
  of drivers/pwm/pwm-nexell.c.
- cosmetic: additional GPL license text removed, SPDX-License-Identifier
  is enough. Furthermore file path removed (two files).

 arch/arm/cpu/armv7/Makefile   |   2 +
 arch/arm/cpu/armv7/s5p4418/Makefile   |   6 +
 arch/arm/cpu/armv7/s5p4418/cpu.c  | 121 ++
 arch/arm/dts/Makefile |   3 +
 arch/arm/dts/s5p4418-nanopi2.dts  | 110 ++
 arch/arm/dts/s5p4418-pinctrl.dtsi | 135 +++
 arch/arm/dts/s5p4418.dtsi | 170 +
 board/friendlyarm/Kconfig |  37 ++
 board/friendlyarm/nanopi2/Kconfig |  12 +
 board/friendlyarm/nanopi2/MAINTAINERS |   7 +
 board/friendlyarm/nanopi2/Makefile|   7 +
 board/friendlyarm/nanopi2/board.c | 575 
 board/friendlyarm/nanopi2/hwrev.c | 108 ++
 board/friendlyarm/nanopi2/hwrev.h |  15 +
 board/friendlyarm/nanopi2/lcds.c  | 697 ++
 board/friendlyarm/nanopi2/nxp-fb.h|  94 +
 board/friendlyarm/nanopi2/onewire.c   | 307 +++
 board/friendlyarm/nanopi2/onewire.h   |  15 +
 18 files changed, 2421 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/s5p4418/Makefile
 create mode 100644 arch/arm/cpu/armv7/s5p4418/cpu.c
 create mode 100644 arch/arm/dts/s5p4418-nanopi2.dts
 create mode 100644 arch/arm/dts/s5p4418-pinctrl.dtsi
 create mode 100644 arch/arm/dts/s5p4418.dtsi
 create mode 100644 board/friendlyarm/Kconfig
 create mode 100644 board/friendlyarm/nanopi2/Kconfig
 create mode 100644 board/friendlyarm/nanopi2/MAINTAINERS
 create mode 100644 board/friendlyarm/nanopi2/Makefile
 create mode 100644 board/friendlyarm/nanopi2/board.c
 create mode 100644 board/friendlyarm/nanopi2/hwrev.c
 create mode 100644 

[PATCH v3 11/14] video: add nexell video driver (soc: dpc, makefile)

2020-06-29 Thread Stefan Bosch
Low level functions for DPC (Display Controller) and Makefile for all
nexell video low level functions.

Signed-off-by: Stefan Bosch 
---

(no changes since v1)

 drivers/video/nexell/soc/Makefile  |   11 +
 drivers/video/nexell/soc/s5pxx18_soc_dpc.c | 1569 
 drivers/video/nexell/soc/s5pxx18_soc_dpc.h |  444 
 3 files changed, 2024 insertions(+)
 create mode 100644 drivers/video/nexell/soc/Makefile
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_dpc.c
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_dpc.h

diff --git a/drivers/video/nexell/soc/Makefile 
b/drivers/video/nexell/soc/Makefile
new file mode 100644
index 000..a3036e5
--- /dev/null
+++ b/drivers/video/nexell/soc/Makefile
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2016 Nexell
+# Junghyun, kim
+
+obj-$(CONFIG_VIDEO_NX) += s5pxx18_soc_dpc.o s5pxx18_soc_mlc.o \
+ s5pxx18_soc_disptop.o s5pxx18_soc_disptop_clk.o
+
+obj-$(CONFIG_VIDEO_NX_LVDS) += s5pxx18_soc_lvds.o
+obj-$(CONFIG_VIDEO_NX_MIPI) += s5pxx18_soc_mipi.o
+obj-$(CONFIG_VIDEO_NX_HDMI) += s5pxx18_soc_hdmi.o
diff --git a/drivers/video/nexell/soc/s5pxx18_soc_dpc.c 
b/drivers/video/nexell/soc/s5pxx18_soc_dpc.c
new file mode 100644
index 000..fc15d6b
--- /dev/null
+++ b/drivers/video/nexell/soc/s5pxx18_soc_dpc.c
@@ -0,0 +1,1569 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016  Nexell Co., Ltd.
+ *
+ * Author: junghyun, kim 
+ */
+
+#include 
+#include 
+
+#include "s5pxx18_soc_dpc.h"
+
+static struct {
+   struct nx_dpc_register_set *pregister;
+} __g_module_variables[NUMBER_OF_DPC_MODULE] = { { NULL,},};
+
+int nx_dpc_initialize(void)
+{
+   static int binit;
+   u32 i;
+
+   if (binit == 0) {
+   for (i = 0; i < NUMBER_OF_DPC_MODULE; i++)
+   __g_module_variables[i].pregister = NULL;
+   binit = 1;
+   }
+   return 1;
+}
+
+u32 nx_dpc_get_number_of_module(void)
+{
+   return NUMBER_OF_DPC_MODULE;
+}
+
+u32 nx_dpc_get_physical_address(u32 module_index)
+{
+   const u32 physical_addr[] = PHY_BASEADDR_DPC_LIST;
+
+   return physical_addr[module_index];
+}
+
+void nx_dpc_set_base_address(u32 module_index, void *base_address)
+{
+   __g_module_variables[module_index].pregister =
+   (struct nx_dpc_register_set *)base_address;
+}
+
+void *nx_dpc_get_base_address(u32 module_index)
+{
+   return (void *)__g_module_variables[module_index].pregister;
+}
+
+void nx_dpc_set_interrupt_enable(u32 module_index, int32_t int_num, int enable)
+{
+   const u32 intenb_pos = 11;
+   const u32 intenb_mask = 1ul << intenb_pos;
+   const u32 intpend_pos = 10;
+   const u32 intpend_mask = 1ul << intpend_pos;
+
+   register u32 regvalue;
+   register struct nx_dpc_register_set *pregister;
+
+   pregister = __g_module_variables[module_index].pregister;
+   regvalue = pregister->dpcctrl0;
+   regvalue &= ~(intenb_mask | intpend_mask);
+   regvalue |= (u32)enable << intenb_pos;
+
+   writel(regvalue, >dpcctrl0);
+}
+
+int nx_dpc_get_interrupt_enable(u32 module_index, int32_t int_num)
+{
+   const u32 intenb_pos = 11;
+   const u32 intenb_mask = 1ul << intenb_pos;
+
+   return (int)((__g_module_variables[module_index].pregister->dpcctrl0 &
+ intenb_mask) >> intenb_pos);
+}
+
+void nx_dpc_set_interrupt_enable32(u32 module_index, u32 enable_flag)
+{
+   const u32 intenb_pos = 11;
+   const u32 intenb_mask = 1 << intenb_pos;
+   const u32 intpend_pos = 10;
+   const u32 intpend_mask = 1 << intpend_pos;
+
+   register struct nx_dpc_register_set *pregister;
+   register u32 read_value;
+
+   pregister = __g_module_variables[module_index].pregister;
+   read_value = pregister->dpcctrl0 & ~(intpend_mask | intenb_mask);
+
+   writel((u32)(read_value | (enable_flag & 0x01) << intenb_pos),
+  >dpcctrl0);
+}
+
+u32 nx_dpc_get_interrupt_enable32(u32 module_index)
+{
+   const u32 intenb_pos = 11;
+   const u32 intenb_mask = 1 << intenb_pos;
+
+   return (u32)((__g_module_variables[module_index].pregister->dpcctrl0 &
+  intenb_mask) >> intenb_pos);
+}
+
+int nx_dpc_get_interrupt_pending(u32 module_index, int32_t int_num)
+{
+   const u32 intpend_pos = 10;
+   const u32 intpend_mask = 1ul << intpend_pos;
+
+   return (int)((__g_module_variables[module_index].pregister->dpcctrl0 &
+ intpend_mask) >> intpend_pos);
+}
+
+u32 nx_dpc_get_interrupt_pending32(u32 module_index)
+{
+   const u32 intpend_pos = 10;
+   const u32 intpend_mask = 1 << intpend_pos;
+
+   return (u32)((__g_module_variables[module_index].pregister->dpcctrl0 &
+  intpend_mask) >> intpend_pos);
+}
+
+void nx_dpc_clear_interrupt_pending(u32 module_index, int32_t int_num)
+{
+   const u32 intpend_pos = 10;
+   register 

[PATCH v3 12/14] video: add nexell video driver (display/video driver)

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- nexell_display.c: Changed to DM, CONFIG_FB_ADDR can not be used
  anymore because framebuffer is allocated by video_reserve() in
  video-uclass.c. Therefore code changed appropriately.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
  possible (and similar).
- livetree API (dev_read_...) is used instead of fdt one (fdt...).

Signed-off-by: Stefan Bosch 
---

Changes in v3:
- drivers/video/nexell/s5pxx18_dp_hdmi.c: '#include ' and
  '#include ' inserted because it has been removed from
  common.h.
- drivers/video/nexell_display.c: '#include ' inserted because
  '#include ' (includes command.h) has been removed from common.h.
- '#ifdef...' changed to 'if (IS_ENABLED(CONFIG...))' where possible
  because of appropriate warnings of patman.
- Changed to livetree API as proposed by patman:
  fdtdec_get_int() --> ofnode_read_s32_default()
  for (node = ...) --> ofnode_for_each_subnode()
  fdt_get_name() --> ofnode_get_name()
  fdt_getprop() --> dev_read_string()
- nx_display_probe() removed, nx_display_dev_probe_uclass() renamed to
  nx_display_probe().

 drivers/video/Kconfig  |  10 +
 drivers/video/Makefile |   1 +
 drivers/video/nexell/Kconfig   |  27 ++
 drivers/video/nexell/Makefile  |  12 +
 drivers/video/nexell/s5pxx18_dp.c  | 341 +
 drivers/video/nexell/s5pxx18_dp_hdmi.c | 545 ++
 drivers/video/nexell/s5pxx18_dp_lvds.c | 274 +
 drivers/video/nexell/s5pxx18_dp_mipi.c | 677 +
 drivers/video/nexell/s5pxx18_dp_rgb.c  |  69 
 drivers/video/nexell_display.c | 651 +++
 10 files changed, 2607 insertions(+)
 create mode 100644 drivers/video/nexell/Kconfig
 create mode 100644 drivers/video/nexell/Makefile
 create mode 100644 drivers/video/nexell/s5pxx18_dp.c
 create mode 100644 drivers/video/nexell/s5pxx18_dp_hdmi.c
 create mode 100644 drivers/video/nexell/s5pxx18_dp_lvds.c
 create mode 100644 drivers/video/nexell/s5pxx18_dp_mipi.c
 create mode 100644 drivers/video/nexell/s5pxx18_dp_rgb.c
 create mode 100644 drivers/video/nexell_display.c

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3812354..fb145e5 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -572,6 +572,16 @@ source "drivers/video/bridge/Kconfig"
 
 source "drivers/video/imx/Kconfig"
 
+config VIDEO_NX
+   bool "Enable video support on Nexell SoC"
+   depends on ARCH_S5P6818 || ARCH_S5P4418
+   help
+  Nexell SoC supports many video output options including eDP and
+  HDMI. This option enables this support which can be used on devices
+  which have an eDP display connected.
+
+source "drivers/video/nexell/Kconfig"
+
 config VIDEO
bool "Enable legacy video support"
depends on !DM_VIDEO
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index df7119d..3bacc64 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -61,6 +61,7 @@ obj-${CONFIG_VIDEO_MIPI_DSI} += mipi_dsi.o
 obj-$(CONFIG_VIDEO_MVEBU) += mvebu_lcd.o
 obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o
 obj-$(CONFIG_VIDEO_MXS) += mxsfb.o videomodes.o
+obj-$(CONFIG_VIDEO_NX) += nexell_display.o videomodes.o nexell/
 obj-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o
 obj-$(CONFIG_VIDEO_DSI_HOST_SANDBOX) += sandbox_dsi_host.o
 obj-$(CONFIG_VIDEO_SANDBOX_SDL) += sandbox_sdl.o
diff --git a/drivers/video/nexell/Kconfig b/drivers/video/nexell/Kconfig
new file mode 100644
index 000..54b8ccb
--- /dev/null
+++ b/drivers/video/nexell/Kconfig
@@ -0,0 +1,27 @@
+if VIDEO_NX
+
+menu "LCD select"
+
+config VIDEO_NX_RGB
+   bool "RGB LCD"
+   help
+ Support for RGB lcd output.
+
+config VIDEO_NX_LVDS
+   bool "LVDS LCD"
+   help
+ Support for LVDS lcd output.
+
+config VIDEO_NX_MIPI
+   bool "MiPi"
+   help
+ Support for MiPi lcd output.
+
+config VIDEO_NX_HDMI
+   bool "HDMI"
+   help
+ Support for hdmi output.
+
+endmenu
+
+endif
diff --git a/drivers/video/nexell/Makefile b/drivers/video/nexell/Makefile
new file mode 100644
index 000..111ab45
--- /dev/null
+++ b/drivers/video/nexell/Makefile
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2016 Nexell
+# Junghyun, kim
+
+obj-$(CONFIG_VIDEO_NX) += s5pxx18_dp.o
+obj-$(CONFIG_VIDEO_NX) += soc/
+
+obj-$(CONFIG_VIDEO_NX_RGB)  += s5pxx18_dp_rgb.o
+obj-$(CONFIG_VIDEO_NX_LVDS) += s5pxx18_dp_lvds.o
+obj-$(CONFIG_VIDEO_NX_MIPI) += s5pxx18_dp_mipi.o
+obj-$(CONFIG_VIDEO_NX_HDMI) += s5pxx18_dp_hdmi.o
diff --git a/drivers/video/nexell/s5pxx18_dp.c 
b/drivers/video/nexell/s5pxx18_dp.c
new file mode 100644
index 000..2248f47
--- /dev/null
+++ b/drivers/video/nexell/s5pxx18_dp.c
@@ -0,0 +1,341 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016  Nexell Co., Ltd.
+ *
+ * Author: junghyun, kim 
+ */
+
+#include 

[PATCH v3 08/14] video: add nexell video driver (soc: displaytop)

2020-06-29 Thread Stefan Bosch
Low level functions for DisplayTop (Display Topology).

Signed-off-by: Stefan Bosch 
---

(no changes since v1)

 drivers/video/nexell/soc/s5pxx18_soc_disptop.c | 185 ++
 drivers/video/nexell/soc/s5pxx18_soc_disptop.h | 385 +
 drivers/video/nexell/soc/s5pxx18_soc_disptop_clk.c | 309 +
 drivers/video/nexell/soc/s5pxx18_soc_disptop_clk.h |  59 
 drivers/video/nexell/soc/s5pxx18_soc_disptype.h|  23 ++
 5 files changed, 961 insertions(+)
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_disptop.c
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_disptop.h
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_disptop_clk.c
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_disptop_clk.h
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_disptype.h

diff --git a/drivers/video/nexell/soc/s5pxx18_soc_disptop.c 
b/drivers/video/nexell/soc/s5pxx18_soc_disptop.c
new file mode 100644
index 000..626e53a
--- /dev/null
+++ b/drivers/video/nexell/soc/s5pxx18_soc_disptop.c
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016  Nexell Co., Ltd.
+ *
+ * Author: junghyun, kim 
+ */
+
+#include 
+#include 
+
+#include "s5pxx18_soc_disptop.h"
+
+static struct {
+   struct nx_disp_top_register_set *pregister;
+} __g_module_variables = { NULL, };
+
+int nx_disp_top_initialize(void)
+{
+   static int binit;
+   u32 i;
+
+   if (binit == 0) {
+   for (i = 0; i < NUMBER_OF_DISPTOP_MODULE; i++)
+   __g_module_variables.pregister = NULL;
+   binit = 1;
+   }
+   return 1;
+}
+
+u32 nx_disp_top_get_number_of_module(void)
+{
+   return NUMBER_OF_DISPTOP_MODULE;
+}
+
+u32 nx_disp_top_get_physical_address(void)
+{
+   static const u32 physical_addr[] = PHY_BASEADDR_DISPTOP_LIST;
+
+   return (u32)(physical_addr[0] + PHY_BASEADDR_DISPLAYTOP_MODULE_OFFSET);
+}
+
+u32 nx_disp_top_get_size_of_register_set(void)
+{
+   return sizeof(struct nx_disp_top_register_set);
+}
+
+void nx_disp_top_set_base_address(void *base_address)
+{
+   __g_module_variables.pregister =
+   (struct nx_disp_top_register_set *)base_address;
+}
+
+void *nx_disp_top_get_base_address(void)
+{
+   return (void *)__g_module_variables.pregister;
+}
+
+void nx_disp_top_set_resconvmux(int benb, u32 sel)
+{
+   register struct nx_disp_top_register_set *pregister;
+   u32 regvalue;
+
+   pregister = __g_module_variables.pregister;
+   regvalue = (benb << 31) | (sel << 0);
+   writel((u32)regvalue, >resconv_mux_ctrl);
+}
+
+void nx_disp_top_set_hdmimux(int benb, u32 sel)
+{
+   register struct nx_disp_top_register_set *pregister;
+   u32 regvalue;
+
+   pregister = __g_module_variables.pregister;
+   regvalue = (benb << 31) | (sel << 0);
+   writel((u32)regvalue, >interconv_mux_ctrl);
+}
+
+void nx_disp_top_set_mipimux(int benb, u32 sel)
+{
+   register struct nx_disp_top_register_set *pregister;
+   u32 regvalue;
+
+   pregister = __g_module_variables.pregister;
+   regvalue = (benb << 31) | (sel << 0);
+   writel((u32)regvalue, >mipi_mux_ctrl);
+}
+
+void nx_disp_top_set_lvdsmux(int benb, u32 sel)
+{
+   register struct nx_disp_top_register_set *pregister;
+   u32 regvalue;
+
+   pregister = __g_module_variables.pregister;
+   regvalue = (benb << 31) | (sel << 0);
+   writel((u32)regvalue, >lvds_mux_ctrl);
+}
+
+void nx_disp_top_set_primary_mux(u32 sel)
+{
+   register struct nx_disp_top_register_set *pregister;
+
+   pregister = __g_module_variables.pregister;
+   writel((u32)sel, >tftmpu_mux);
+}
+
+void nx_disp_top_hdmi_set_vsync_start(u32 sel)
+{
+   register struct nx_disp_top_register_set *pregister;
+
+   pregister = __g_module_variables.pregister;
+   writel((u32)sel, >hdmisyncctrl0);
+}
+
+void nx_disp_top_hdmi_set_vsync_hsstart_end(u32 start, u32 end)
+{
+   register struct nx_disp_top_register_set *pregister;
+
+   pregister = __g_module_variables.pregister;
+   writel((u32)(end << 16) | (start << 0), >hdmisyncctrl3);
+}
+
+void nx_disp_top_hdmi_set_hactive_start(u32 sel)
+{
+   register struct nx_disp_top_register_set *pregister;
+
+   pregister = __g_module_variables.pregister;
+   writel((u32)sel, >hdmisyncctrl1);
+}
+
+void nx_disp_top_hdmi_set_hactive_end(u32 sel)
+{
+   register struct nx_disp_top_register_set *pregister;
+
+   pregister = __g_module_variables.pregister;
+   writel((u32)sel, >hdmisyncctrl2);
+}
+
+void nx_disp_top_set_hdmifield(u32 enable, u32 init_val, u32 vsynctoggle,
+  u32 hsynctoggle, u32 vsyncclr, u32 hsyncclr,
+  u32 field_use, u32 muxsel)
+{
+   register struct nx_disp_top_register_set *pregister;
+   u32 regvalue;
+
+   pregister = __g_module_variables.pregister;
+   regvalue = ((enable & 0x01) << 0) | 

[PATCH v3 10/14] video: add nexell video driver (soc: lvds, hdmi)

2020-06-29 Thread Stefan Bosch
Low level functions for LVDS and HDMI display interfaces.

Signed-off-by: Stefan Bosch 
---

(no changes since v1)

 drivers/video/nexell/soc/s5pxx18_soc_hdmi.c |  50 +++
 drivers/video/nexell/soc/s5pxx18_soc_hdmi.h | 488 
 drivers/video/nexell/soc/s5pxx18_soc_lvds.c | 278 
 drivers/video/nexell/soc/s5pxx18_soc_lvds.h |  83 +
 4 files changed, 899 insertions(+)
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_hdmi.c
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_hdmi.h
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_lvds.c
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_lvds.h

diff --git a/drivers/video/nexell/soc/s5pxx18_soc_hdmi.c 
b/drivers/video/nexell/soc/s5pxx18_soc_hdmi.c
new file mode 100644
index 000..7b8be7e
--- /dev/null
+++ b/drivers/video/nexell/soc/s5pxx18_soc_hdmi.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016  Nexell Co., Ltd.
+ *
+ * Author: junghyun, kim 
+ */
+
+#include 
+#include 
+
+#include "s5pxx18_soc_hdmi.h"
+
+static u32 *hdmi_base_addr;
+
+u32 nx_hdmi_get_reg(u32 module_index, u32 offset)
+{
+   u32 *reg_addr;
+   u32 regvalue;
+
+   reg_addr = hdmi_base_addr + (offset / sizeof(u32));
+   regvalue = readl((u32 *)reg_addr);
+
+   return regvalue;
+}
+
+void nx_hdmi_set_reg(u32 module_index, u32 offset, u32 regvalue)
+{
+   s64 offset_new = (s64)((int32_t)offset);
+   u32 *reg_addr;
+
+   reg_addr = hdmi_base_addr + (offset_new / sizeof(u32));
+   writel(regvalue, (u32 *)reg_addr);
+}
+
+void nx_hdmi_set_base_address(u32 module_index, void *base_address)
+{
+   hdmi_base_addr = (u32 *)base_address;
+}
+
+void *nx_hdmi_get_base_address(u32 module_index)
+{
+   return (u32 *)hdmi_base_addr;
+}
+
+u32 nx_hdmi_get_physical_address(u32 module_index)
+{
+   const u32 physical_addr[] = PHY_BASEADDR_HDMI_LIST;
+
+   return physical_addr[module_index];
+}
diff --git a/drivers/video/nexell/soc/s5pxx18_soc_hdmi.h 
b/drivers/video/nexell/soc/s5pxx18_soc_hdmi.h
new file mode 100644
index 000..a4c5ab5
--- /dev/null
+++ b/drivers/video/nexell/soc/s5pxx18_soc_hdmi.h
@@ -0,0 +1,488 @@
+/* SPDX-License-Identifier: GPL-2.0+
+ *
+ * Copyright (C) 2016  Nexell Co., Ltd.
+ *
+ * Author: junghyun, kim 
+ */
+
+#ifndef _S5PXX18_SOC_HDMI_H_
+#define _S5PXX18_SOC_HDMI_H_
+
+#include "s5pxx18_soc_disptop.h"
+
+#define PHY_BASEADDR_HDMI_PHY_MODULE   0xc00f
+#define PHY_BASEADDR_HDMI_LIST \
+   { PHY_BASEADDR_HDMI_MODULE }
+
+#define HDMI_LINK_INTC_CON_0   (HDMI_ADDR_OFFSET + 0x)
+#define HDMI_LINK_INTC_FLAG_0  (HDMI_ADDR_OFFSET + 0x0004)
+#define HDMI_LINK_AESKEY_VALID (HDMI_ADDR_OFFSET + 0x0008)
+#define HDMI_LINK_HPD  (HDMI_ADDR_OFFSET + 0x000C)
+#define HDMI_LINK_INTC_CON_1   (HDMI_ADDR_OFFSET + 0x0010)
+#define HDMI_LINK_INTC_FLAG_1  (HDMI_ADDR_OFFSET + 0x0014)
+#define HDMI_LINK_PHY_STATUS_0 (HDMI_ADDR_OFFSET + 0x0020)
+#define HDMI_LINK_PHY_STATUS_CMU   (HDMI_ADDR_OFFSET + 0x0024)
+#define HDMI_LINK_PHY_STATUS_PLL   (HDMI_ADDR_OFFSET + 0x0028)
+#define HDMI_LINK_PHY_CON_0(HDMI_ADDR_OFFSET + 0x0030)
+#define HDMI_LINK_HPD_CTRL (HDMI_ADDR_OFFSET + 0x0040)
+#define HDMI_LINK_HPD_STATUS   (HDMI_ADDR_OFFSET + 0x0044)
+#define HDMI_LINK_HPD_TH_x (HDMI_ADDR_OFFSET + 0x0050)
+
+#define HDMI_LINK_HDMI_CON_0   (HDMI_ADDR_OFFSET + 0x0001)
+#define HDMI_LINK_HDMI_CON_1   (HDMI_ADDR_OFFSET + 0x00010004)
+#define HDMI_LINK_HDMI_CON_2   (HDMI_ADDR_OFFSET + 0x00010008)
+#define HDMI_LINK_STATUS   (HDMI_ADDR_OFFSET + 0x00010010)
+#define HDMI_LINK_STATUS_EN(HDMI_ADDR_OFFSET + 0x00010020)
+
+#define HDMI_LINK_HDCP_SHA1_REN0   (HDMI_ADDR_OFFSET + 0x00010024)
+#define HDMI_LINK_HDCP_SHA1_REN1   (HDMI_ADDR_OFFSET + 0x00010028)
+
+#define HDMI_LINK_MODE_SEL (HDMI_ADDR_OFFSET + 0x00010040)
+#define HDMI_LINK_ENC_EN   (HDMI_ADDR_OFFSET + 0x00010044)
+#define HDMI_LINK_HDMI_YMAX(HDMI_ADDR_OFFSET + 0x00010060)
+#define HDMI_LINK_HDMI_YMIN(HDMI_ADDR_OFFSET + 0x00010064)
+#define HDMI_LINK_HDMI_CMAX(HDMI_ADDR_OFFSET + 0x00010068)
+#define HDMI_LINK_HDMI_CMIN(HDMI_ADDR_OFFSET + 0x0001006C)
+#define HDMI_LINK_H_BLANK_0(HDMI_ADDR_OFFSET + 0x000100A0)
+#define HDMI_LINK_H_BLANK_1(HDMI_ADDR_OFFSET + 0x000100A4)
+#define HDMI_LINK_V2_BLANK_0   (HDMI_ADDR_OFFSET + 0x000100B0)
+#define HDMI_LINK_V2_BLANK_1   (HDMI_ADDR_OFFSET + 0x000100B4)
+#define HDMI_LINK_V1_BLANK_0   (HDMI_ADDR_OFFSET + 0x000100B8)
+#define HDMI_LINK_V1_BLANK_1   (HDMI_ADDR_OFFSET + 0x000100BC)
+#define 

[PATCH v3 07/14] pwm: add driver for nexell

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- Since drivers/pwm/pwm-nexell.c is an adapted version of
  s5p-common/pwm.c an appropriately changed version of s5p-common/pwm.c
  is used instead. Therefore arch/arm/mach-s5pc1xx/include/mach/pwm.h
  copied to arch/arm/mach-nexell/include/mach and s5p-common/Makefile
  changed appropriately.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
  possible (and similar).

Signed-off-by: Stefan Bosch 
---

Changes in v3:
- Handling of Configs for LCD backlight control reworked because (among
  others) not setting CONFIG_S5P4418_ONEWIRE and/or CONFIG_PWM_NX has
  caused errors when compiling board/friendlyarm/nanopi2/onewire.c.
- pwm.h: () around macro argument x added to avoid precedence issues.
- '#ifdef...' changed to 'if (IS_ENABLED(CONFIG...))' where possible
  because of appropriate warnings of patman.

Changes in v2:
- commit "i2c: mmc: add nexell driver (gpio, i2c, mmc, pwm)" splitted
  into separate commits for gpio, i2c, mmc, pwm.
- Since drivers/pwm/pwm-nexell.c is an adapted version of
  s5p-common/pwm.c an appropriately changed version of s5p-common/pwm.c
  is used now. Therefore arch/arm/mach-s5pc1xx/include/mach/pwm.h
  copied to arch/arm/mach-nexell/include/mach and s5p-common/Makefile
  changed appropriately.

 arch/arm/cpu/armv7/s5p-common/Makefile  | 13 +---
 arch/arm/cpu/armv7/s5p-common/pwm.c | 57 -
 arch/arm/mach-nexell/include/mach/pwm.h | 54 +++
 3 files changed, 119 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-nexell/include/mach/pwm.h

diff --git a/arch/arm/cpu/armv7/s5p-common/Makefile 
b/arch/arm/cpu/armv7/s5p-common/Makefile
index 12cf804..bfe0238 100644
--- a/arch/arm/cpu/armv7/s5p-common/Makefile
+++ b/arch/arm/cpu/armv7/s5p-common/Makefile
@@ -3,9 +3,14 @@
 # Copyright (C) 2009 Samsung Electronics
 # Minkyu Kang 
 
-obj-y  += cpu_info.o
+ifdef CONFIG_ARCH_NEXELL
+obj-$(CONFIG_PWM_NX) += pwm.o
+obj-$(CONFIG_S5P4418_ONEWIRE) += pwm.o
+else
+obj-y += cpu_info.o
 ifndef CONFIG_SPL_BUILD
-obj-y  += timer.o
-obj-y  += sromc.o
-obj-$(CONFIG_PWM)  += pwm.o
+obj-y += timer.o
+obj-y += sromc.o
+obj-$(CONFIG_PWM) += pwm.o
+endif
 endif
diff --git a/arch/arm/cpu/armv7/s5p-common/pwm.c 
b/arch/arm/cpu/armv7/s5p-common/pwm.c
index 6b9e865..aef2e55 100644
--- a/arch/arm/cpu/armv7/s5p-common/pwm.c
+++ b/arch/arm/cpu/armv7/s5p-common/pwm.c
@@ -15,7 +15,11 @@
 int pwm_enable(int pwm_id)
 {
const struct s5p_timer *pwm =
+#if defined(CONFIG_ARCH_NEXELL)
+   (struct s5p_timer *)PHY_BASEADDR_PWM;
+#else
(struct s5p_timer *)samsung_get_base_timer();
+#endif
unsigned long tcon;
 
tcon = readl(>tcon);
@@ -29,7 +33,11 @@ int pwm_enable(int pwm_id)
 void pwm_disable(int pwm_id)
 {
const struct s5p_timer *pwm =
+#if defined(CONFIG_ARCH_NEXELL)
+   (struct s5p_timer *)PHY_BASEADDR_PWM;
+#else
(struct s5p_timer *)samsung_get_base_timer();
+#endif
unsigned long tcon;
 
tcon = readl(>tcon);
@@ -43,14 +51,43 @@ static unsigned long pwm_calc_tin(int pwm_id, unsigned long 
freq)
unsigned long tin_parent_rate;
unsigned int div;
 
+#if defined(CONFIG_ARCH_NEXELL)
+   unsigned int pre_div;
+   const struct s5p_timer *pwm =
+   (struct s5p_timer *)PHY_BASEADDR_PWM;
+   unsigned int val;
+   struct clk *clk = clk_get(CORECLK_NAME_PCLK);
+
+   tin_parent_rate = clk_get_rate(clk);
+#else
tin_parent_rate = get_pwm_clk();
+#endif
+
+#if defined(CONFIG_ARCH_NEXELL)
+   writel(0, >tcfg0);
+   val = readl(>tcfg0);
+
+   if (pwm_id < 2)
+   div = ((val >> 0) & 0xff) + 1;
+   else
+   div = ((val >> 8) & 0xff) + 1;
 
+   writel(0, >tcfg1);
+   val = readl(>tcfg1);
+   val = (val >> MUX_DIV_SHIFT(pwm_id)) & 0xF;
+   pre_div = (1UL << val);
+
+   freq = tin_parent_rate / div / pre_div;
+
+   return freq;
+#else
for (div = 2; div <= 16; div *= 2) {
if ((tin_parent_rate / (div << 16)) < freq)
return tin_parent_rate / div;
}
 
return tin_parent_rate / 16;
+#endif
 }
 
 #define NS_IN_SEC 10UL
@@ -58,7 +95,11 @@ static unsigned long pwm_calc_tin(int pwm_id, unsigned long 
freq)
 int pwm_config(int pwm_id, int duty_ns, int period_ns)
 {
const struct s5p_timer *pwm =
+#if defined(CONFIG_ARCH_NEXELL)
+   (struct s5p_timer *)PHY_BASEADDR_PWM;
+#else
(struct s5p_timer *)samsung_get_base_timer();
+#endif
unsigned int offset;
unsigned long tin_rate;
unsigned long tin_ns;
@@ -84,7 +125,12 @@ int pwm_config(int pwm_id, int duty_ns, int period_ns)
tin_rate = pwm_calc_tin(pwm_id, frequency);
 
tin_ns = NS_IN_SEC / tin_rate;
-   tcnt = 

[PATCH v3 06/14] pinctrl: add nexell driver

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- livetree API (dev_read_...) is used instead of fdt one (fdt...).
- doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt added.

Signed-off-by: Stefan Bosch 
---

Changes in v3:
- Kconfig: Missing helps added.
- Changed to livetree API as proposed by patman:
  fdt_stringlist_count() --> dev_read_string_count()
  fdt_stringlist_get() --> dev_read_string_index()
  fdtdec_get_int() --> dev_read_s32_default()
- doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt added.

 .../pinctrl/nexell,s5pxx18-pinctrl.txt |  78 
 drivers/pinctrl/Kconfig|   1 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/nexell/Kconfig |  18 ++
 drivers/pinctrl/nexell/Makefile|   7 +
 drivers/pinctrl/nexell/pinctrl-nexell.c|  66 +++
 drivers/pinctrl/nexell/pinctrl-nexell.h|  68 +++
 drivers/pinctrl/nexell/pinctrl-s5pxx18.c   | 220 +
 drivers/pinctrl/nexell/pinctrl-s5pxx18.h   |  53 +
 9 files changed, 512 insertions(+)
 create mode 100644 doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt
 create mode 100644 drivers/pinctrl/nexell/Kconfig
 create mode 100644 drivers/pinctrl/nexell/Makefile
 create mode 100644 drivers/pinctrl/nexell/pinctrl-nexell.c
 create mode 100644 drivers/pinctrl/nexell/pinctrl-nexell.h
 create mode 100644 drivers/pinctrl/nexell/pinctrl-s5pxx18.c
 create mode 100644 drivers/pinctrl/nexell/pinctrl-s5pxx18.h

diff --git a/doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt 
b/doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt
new file mode 100644
index 000..115ab53
--- /dev/null
+++ b/doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt
@@ -0,0 +1,78 @@
+Binding for Nexell s5pxx18 pin cotroller
+
+
+Nexell's ARM bases SoC's integrates a GPIO and Pin mux/config hardware
+controller. It controls the input/output settings on the available pads/pins
+and also provides ability to multiplex and configure the output of various
+on-chip controllers onto these pads.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+
+Required properties:
+  - compatible: "nexell,s5pxx18-pinctrl"
+  - reg: should be register base and length as documented in the datasheet
+  - interrupts: interrupt specifier for the controller over gpio and alive pins
+
+Example:
+pinctrl_0: pinctrl@c001 {
+   compatible = "nexell,s5pxx18-pinctrl";
+   reg = <0xc001 0xf000>;
+   u-boot,dm-pre-reloc;
+};
+
+Nexell's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters.
+
+  Child nodes must be set at least one of the following settings:
+  - pins = Select pins for using this function.
+  - pin-function = Select the function for use in a selected pin.
+  - pin-pull = Pull up/down configuration.
+  - pin-strength = Drive strength configuration.
+
+  Valid values for nexell,pins are:
+ "gpioX-N" : X in {A,B,C,D,E}, N in {0-31}
+  Valid values for nexell,pin-function are:
+ "N"   : N in {0-3}.
+ This setting means that the value is different for each pin.
+ Please refer to datasheet.
+  Valid values for nexell,pin-pull are:
+ "N"   : 0 - Down, 1 - Up, 2 - Off
+  Valid values for nexell,pin-strength are:
+ "N"   : 0,1,2,3
+
+
+Example:
+  - pin settings
+   mmc0_clk: mmc0-clk {
+   pins = "gpioa-29";
+   pin-function = <1>;
+   pin-pull = <2>;
+   pin-strength = <2>;
+   };
+
+   mmc0_cmd: mmc0-cmd {
+   pins = "gpioa-31";
+   pin-function = <1>;
+   pin-pull = <2>;
+   pin-strength = <1>;
+   };
+
+   mmc0_bus4: mmc0-bus-width4 {
+   pins = "gpiob-1, gpiob-3, gpiob-5, gpiob-7";
+   pin-function = <1>;
+   pin-pull = <2>;
+   pin-strength = <1>;
+   };
+
+  - used by client devices
+   mmc0:mmc@... {
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk>, <_cmd>, <_bus4>;
+   ...
+   };
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 83e39b9..bd2061b 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -294,6 +294,7 @@ source "drivers/pinctrl/meson/Kconfig"
 source "drivers/pinctrl/mscc/Kconfig"
 source "drivers/pinctrl/mtmips/Kconfig"
 source "drivers/pinctrl/mvebu/Kconfig"
+source 

[PATCH v3 09/14] video: add nexell video driver (soc: mlc, mipi)

2020-06-29 Thread Stefan Bosch
Low level functions for MLC (Multi Layer Control) and MIPI (Mobile
Industry Processor Interface).

Signed-off-by: Stefan Bosch 
---

(no changes since v1)

 drivers/video/nexell/soc/s5pxx18_soc_mipi.c |  580 +
 drivers/video/nexell/soc/s5pxx18_soc_mipi.h |  291 +
 drivers/video/nexell/soc/s5pxx18_soc_mlc.c  | 1861 +++
 drivers/video/nexell/soc/s5pxx18_soc_mlc.h  |  429 ++
 4 files changed, 3161 insertions(+)
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_mipi.c
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_mipi.h
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_mlc.c
 create mode 100644 drivers/video/nexell/soc/s5pxx18_soc_mlc.h

diff --git a/drivers/video/nexell/soc/s5pxx18_soc_mipi.c 
b/drivers/video/nexell/soc/s5pxx18_soc_mipi.c
new file mode 100644
index 000..1000ddb
--- /dev/null
+++ b/drivers/video/nexell/soc/s5pxx18_soc_mipi.c
@@ -0,0 +1,580 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016  Nexell Co., Ltd.
+ *
+ * Author: junghyun, kim 
+ */
+
+#include 
+#include 
+
+#include "s5pxx18_soc_disptop.h"
+#include "s5pxx18_soc_mipi.h"
+
+static struct nx_mipi_register_set *__g_pregister[NUMBER_OF_MIPI_MODULE];
+
+int nx_mipi_smoke_test(u32 module_index)
+{
+   register struct nx_mipi_register_set *pregister;
+
+   pregister = __g_pregister[module_index];
+
+   if (pregister->csis_config_ch0 != 0x00FC)
+   return false;
+
+   if (pregister->dsim_intmsk != 0xB337)
+   return false;
+
+   writel(0xDEADC0DE, >csis_dphyctrl);
+   writel(0x, >csis_ctrl2);
+   writel(0xDEADC0DE, >dsim_msync);
+
+   if (pregister->csis_dphyctrl != 0xDE80001E)
+   return false;
+
+   if ((pregister->csis_ctrl2 & (~1)) != 0xEEE00010)
+   return false;
+
+   if (pregister->dsim_msync != 0xDE80C0DE)
+   return false;
+
+   return true;
+}
+
+void nx_mipi_set_base_address(u32 module_index, void *base_address)
+{
+   __g_pregister[module_index] =
+   (struct nx_mipi_register_set *)base_address;
+}
+
+void *nx_mipi_get_base_address(u32 module_index)
+{
+   return (void *)__g_pregister[module_index];
+}
+
+u32 nx_mipi_get_physical_address(u32 module_index)
+{
+   const u32 physical_addr[] = PHY_BASEADDR_MIPI_LIST;
+
+   return physical_addr[module_index];
+}
+
+#define __nx_mipi_valid_dsi_intmask__  \
+   (~((1 << 26) | (1 << 23) | (1 << 22) | (1 << 19)))
+
+void nx_mipi_set_interrupt_enable(u32 module_index, u32 int_num, int enable)
+{
+   register struct nx_mipi_register_set *pregister;
+   register u32 regvalue;
+
+   pregister = __g_pregister[module_index];
+   if (int_num < 32) {
+   regvalue = pregister->csis_intmsk;
+   regvalue &= ~(1ul << int_num);
+   regvalue |= (u32)enable << int_num;
+   writel(regvalue, >csis_intmsk);
+   } else {
+   regvalue = pregister->dsim_intmsk;
+   regvalue &= ~(1ul << (int_num - 32));
+   regvalue |= (u32)enable << (int_num - 32);
+   writel(regvalue, >dsim_intmsk);
+   }
+}
+
+int nx_mipi_get_interrupt_enable(u32 module_index, u32 int_num)
+{
+   if (int_num < 32)
+   return (int)((__g_pregister[module_index]->csis_intmsk >>
+ int_num) & 0x01);
+   else
+   return (int)((__g_pregister[module_index]->dsim_intmsk >>
+ (int_num - 32)) & 0x01);
+}
+
+int nx_mipi_get_interrupt_pending(u32 module_index, u32 int_num)
+{
+   register struct nx_mipi_register_set *pregister;
+   register u32 regvalue;
+   int ret;
+
+   pregister = __g_pregister[module_index];
+   if (int_num < 32) {
+   regvalue = pregister->csis_intmsk;
+   regvalue &= pregister->csis_intsrc;
+   ret = (int)((regvalue >> int_num) & 0x01);
+   } else {
+   regvalue = pregister->dsim_intmsk;
+   regvalue &= pregister->dsim_intsrc;
+   ret = (int)((regvalue >> (int_num - 32)) & 0x01);
+   }
+
+   return ret;
+}
+
+void nx_mipi_clear_interrupt_pending(u32 module_index, u32 int_num)
+{
+   register struct nx_mipi_register_set *pregister;
+
+   pregister = __g_pregister[module_index];
+   if (int_num < 32)
+   writel(1ul << int_num, >csis_intsrc);
+   else
+   writel(1ul << (int_num - 32), >dsim_intsrc);
+}
+
+void nx_mipi_set_interrupt_enable_all(u32 module_index, int enable)
+{
+   register struct nx_mipi_register_set *pregister;
+
+   pregister = __g_pregister[module_index];
+   if (enable)
+   writel(__nx_mipi_valid_dsi_intmask__, >dsim_intmsk);
+   else
+   writel(0, >dsim_intmsk);
+}
+
+int nx_mipi_get_interrupt_enable_all(u32 module_index)
+{
+   if (__g_pregister[module_index]->csis_intmsk)
+   

[PATCH v3 05/14] mmc: add nexell driver

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- driver changed to DM.
- pinctrl-driver/dt is used now instead of configuring the mmc I/O-pins
  in the mmc-driver.
- nexell_dwmmc_ofdata_to_platdata() reworked, i.e. valid default values
  are used now (where possible) and the appropriate if-blocks have
  been removed.
- new dt-property "mmcboost" is used now instead of "CONFIG_BOOST_MMC"
  which was not defined anywhere.

Signed-off-by: Stefan Bosch 
---

Changes in v3:
- nexell_dw_mmc_dm.c renamed (back) to nexell_dw_mmc.c
- pinctrl-driver/dt is used now instead of configuring the mmc I/O-pins
  in the mmc-driver.
- nexell_dwmmc_ofdata_to_platdata() reworked, i.e. valid default values
  are used now (where possible) and the appropriate if-blocks have
  been removed.
- "nexell," removed from dt-properties, e.g. "nexell,bus-width" changed
  to "bus-width".
- new dt-property "mmcboost" is used now instead of "CONFIG_BOOST_MMC"
  which was not defined anywhere.
- Boot error "Loading Environment from MMC... *** Warning - No block
  device, using default environment" after updating local repository.
  Bugfix in drivers/mmc/nexell_dw_mmc.c: "#include " changed to
  "#include ". This Bug showed up now because of the
  commit "dm: clk: add stub when CONFIG_CLK is deactivated" where
  include/clk.h has been changed.
- drivers/mmc/nexell_dw_mmc.c: '#include ' inserted because it
  has been removed from common.h.

Changes in v2:
- commit "i2c: mmc: add nexell driver (gpio, i2c, mmc, pwm)" splitted
  into separate commits for gpio, i2c, mmc, pwm.

 drivers/mmc/Kconfig |   8 ++
 drivers/mmc/Makefile|   1 +
 drivers/mmc/nexell_dw_mmc.c | 237 
 3 files changed, 246 insertions(+)
 create mode 100644 drivers/mmc/nexell_dw_mmc.c

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 3c4f057..5fc47c8 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -264,6 +264,14 @@ config MMC_DW_SNPS
  This selects support for Synopsys DesignWare Memory Card Interface 
driver
  extensions used in various Synopsys ARC devboards.
 
+config NEXELL_DWMMC
+   bool "Nexell SD/MMC controller support"
+   depends on ARCH_NEXELL
+   depends on MMC_DW
+   depends on DM_MMC
+   depends on PINCTRL_NEXELL
+   default y
+
 config MMC_MESON_GX
bool "Meson GX EMMC controller support"
depends on DM_MMC && BLK && ARCH_MESON
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index e84c792..d375669 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o
 obj-$(CONFIG_SH_SDHI) += sh_sdhi.o
 obj-$(CONFIG_STM32_SDMMC2) += stm32_sdmmc2.o
 obj-$(CONFIG_JZ47XX_MMC) += jz_mmc.o
+obj-$(CONFIG_NEXELL_DWMMC) += nexell_dw_mmc.o
 
 # SDHCI
 obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
diff --git a/drivers/mmc/nexell_dw_mmc.c b/drivers/mmc/nexell_dw_mmc.c
new file mode 100644
index 000..0462759
--- /dev/null
+++ b/drivers/mmc/nexell_dw_mmc.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2016 Nexell
+ * Youngbok, Park 
+ *
+ * (C) Copyright 2019 Stefan Bosch 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DWMCI_CLKSEL   0x09C
+#define DWMCI_SHIFT_0  0x0
+#define DWMCI_SHIFT_1  0x1
+#define DWMCI_SHIFT_2  0x2
+#define DWMCI_SHIFT_3  0x3
+#define DWMCI_SET_SAMPLE_CLK(x)(x)
+#define DWMCI_SET_DRV_CLK(x)   ((x) << 16)
+#define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
+#define DWMCI_CLKCTRL  0x114
+#define NX_MMC_CLK_DELAY(x, y, a, b)   x) & 0xFF) << 0) |\
+   (((y) & 0x03) << 16) |\
+   (((a) & 0xFF) << 8)  |\
+   (((b) & 0x03) << 24))
+
+struct nexell_mmc_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
+struct nexell_dwmmc_priv {
+   struct clk *clk;
+   struct dwmci_host host;
+   int fifo_size;
+   bool fifo_mode;
+   int frequency;
+   u32 min_freq;
+   u32 max_freq;
+   int d_delay;
+   int d_shift;
+   int s_delay;
+   int s_shift;
+   bool mmcboost;
+};
+
+struct clk *clk_get(const char *id);
+
+static void nx_dw_mmc_clksel(struct dwmci_host *host)
+{
+   /* host->priv is pointer to "struct udevice" */
+   struct nexell_dwmmc_priv *priv = dev_get_priv(host->priv);
+   u32 val;
+
+   if (priv->mmcboost)
+   val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
+ DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(1);
+   else
+   val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
+ DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(3);
+
+   dwmci_writel(host, DWMCI_CLKSEL, val);
+}
+
+static void 

[PATCH v3 04/14] i2c: add nexell driver

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- i2c/nx_i2c.c: Some adaptions mainly because of changes in
  "struct udevice".
- several Bugfixes in nx_i2c.c.
- the driver has been for s5p6818 only. Code extended appropriately
  in order s5p4418 is also working.
- "probe_chip" added.
- pinctrl-driver/dt is used instead of configuring the i2c I/O-pins
  in the i2c-driver.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
  possible (and similar).
- livetree API (dev_read_...) is used instead of fdt one (fdt...).

Signed-off-by: Stefan Bosch 
---

Changes in v3:
- pinctrl-driver/dt is used now instead of configuring the i2c I/O-pins
  in the i2c-driver.
- drivers/i2c/nx_i2c.c: '#include ' inserted because it has been
  removed from common.h.
- '#ifdef...' changed to 'if (IS_ENABLED(CONFIG...))' where possible
  because of appropriate warnings of patman.
- Changed to livetree API as proposed by patman:
  fdtdec_get_int() --> dev_read_s32_default()

Changes in v2:
- commit "i2c: mmc: add nexell driver (gpio, i2c, mmc, pwm)" splitted
  into separate commits for gpio, i2c, mmc, pwm.
- several Bugfixes in nx_i2c.c.
- the i2c-driver has been for s5p6818 only. Code extended approriately
  in order s5p4418 is also working.
- "probe_chip" added to the i2c-driver.
- doc/device-tree-bindings/i2c/nx_i2c.txt added.

 doc/device-tree-bindings/i2c/nx_i2c.txt |  28 ++
 drivers/i2c/Kconfig |   9 +
 drivers/i2c/Makefile|   1 +
 drivers/i2c/nx_i2c.c| 624 
 4 files changed, 662 insertions(+)
 create mode 100644 doc/device-tree-bindings/i2c/nx_i2c.txt
 create mode 100644 drivers/i2c/nx_i2c.c

diff --git a/doc/device-tree-bindings/i2c/nx_i2c.txt 
b/doc/device-tree-bindings/i2c/nx_i2c.txt
new file mode 100644
index 000..9f3abe7
--- /dev/null
+++ b/doc/device-tree-bindings/i2c/nx_i2c.txt
@@ -0,0 +1,28 @@
+I2C controller embedded in Nexell's/Samsung's SoC S5P4418 and S5P6818
+
+Driver:
+- drivers/i2c/nx_i2c.c
+
+Required properties:
+- #address-cells = <1>;
+- #size-cells = <0>;
+- compatible = "nexell,s5pxx18-i2c";
+- reg = ;
+Where i2c_base has to be the base address of the i2c-register set.
+I2C0: 0xc00a4000
+I2C1: 0xc00a5000
+I2C2: 0xc00a6000
+
+Optional properties:
+- clock-frequency: Desired I2C bus frequency in Hz, default value is 10.
+- i2c-sda-delay-ns (S5P6818 only): SDA delay in ns, default value is 0.
+- Child nodes conforming to i2c bus binding.
+
+Example:
+   i2c0:i2c@c00a4000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "nexell,s5pxx18-i2c";
+   reg = <0xc00a4000 0x100>;
+   clock-frequency = <40>;
+   };
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index f8b18de..b276f0b 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -325,6 +325,15 @@ config SYS_MXC_I2C8_SLAVE
 MXC I2C8 Slave
 endif
 
+config SYS_I2C_NEXELL
+   bool "Nexell I2C driver"
+   depends on DM_I2C
+   help
+ Add support for the Nexell I2C driver. This is used with various
+ Nexell parts such as S5Pxx18 series SoCs. All chips
+ have several I2C ports and all are provided, controlled by the
+ device tree.
+
 config SYS_I2C_OMAP24XX
bool "TI OMAP2+ I2C driver"
depends on ARCH_OMAP2PLUS || ARCH_K3
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 62935b7..6ebc1aa 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_SYS_I2C_LPC32XX) += lpc32xx_i2c.o
 obj-$(CONFIG_SYS_I2C_MESON) += meson_i2c.o
 obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
 obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
+obj-$(CONFIG_SYS_I2C_NEXELL) += nx_i2c.o
 obj-$(CONFIG_SYS_I2C_OMAP24XX) += omap24xx_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR_I2C) += rcar_i2c.o
 obj-$(CONFIG_SYS_I2C_RCAR_IIC) += rcar_iic.o
diff --git a/drivers/i2c/nx_i2c.c b/drivers/i2c/nx_i2c.c
new file mode 100644
index 000..cefc774
--- /dev/null
+++ b/drivers/i2c/nx_i2c.c
@@ -0,0 +1,624 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define I2C_WRITE   0
+#define I2C_READ1
+
+#define I2CSTAT_MTM 0xC0/* Master Transmit Mode */
+#define I2CSTAT_MRM 0x80/* Master Receive Mode */
+#define I2CSTAT_BSY 0x20/* Read: Bus Busy */
+#define I2CSTAT_SS  0x20/* Write: START (1) / STOP (0) */
+#define I2CSTAT_RXTXEN  0x10/* Rx/Tx enable */
+#define I2CSTAT_ABT0x08/* Arbitration bit */
+#define I2CSTAT_NACK0x01/* Nack bit */
+#define I2CCON_IRCLR0x100   /* Interrupt Clear bit  */
+#define I2CCON_ACKGEN   0x80/* Acknowledge generation */
+#define I2CCON_IRENB   0x20/* Interrupt Enable bit  */
+#define I2CCON_IRPND0x10/* Interrupt pending bit */
+
+#ifdef CONFIG_ARCH_S5P6818
+#define I2CLC_FILTER   0x04/* 

[PATCH v3 01/14] arm: add mach-nexell (header files)

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- DM_VIDEO support (display_dev.h).
- boot0.h added, handles NSIH --> tools/nexell obsolete.
- gpio.h: Include-path to errno.h changed.

Signed-off-by: Stefan Bosch 
---

(no changes since v2)

Changes in v2:
- cosmetic: additional GPL license text removed, SPDX-License-Identifier
  is enough.

 arch/arm/mach-nexell/include/mach/boot0.h|  40 +++
 arch/arm/mach-nexell/include/mach/clk.h  |  24 ++
 arch/arm/mach-nexell/include/mach/display.h  | 273 +++
 arch/arm/mach-nexell/include/mach/display_dev.h  |  37 ++
 arch/arm/mach-nexell/include/mach/ehci.h | 106 ++
 arch/arm/mach-nexell/include/mach/gpio.h |  17 +
 arch/arm/mach-nexell/include/mach/mipi_display.h | 215 
 arch/arm/mach-nexell/include/mach/nexell.h   | 352 +++
 arch/arm/mach-nexell/include/mach/nx_gpio.h  | 103 ++
 arch/arm/mach-nexell/include/mach/reset.h|  19 +
 arch/arm/mach-nexell/include/mach/sec_reg.h  |  15 +
 arch/arm/mach-nexell/include/mach/tieoff.h   | 423 +++
 12 files changed, 1624 insertions(+)
 create mode 100644 arch/arm/mach-nexell/include/mach/boot0.h
 create mode 100644 arch/arm/mach-nexell/include/mach/clk.h
 create mode 100644 arch/arm/mach-nexell/include/mach/display.h
 create mode 100644 arch/arm/mach-nexell/include/mach/display_dev.h
 create mode 100644 arch/arm/mach-nexell/include/mach/ehci.h
 create mode 100644 arch/arm/mach-nexell/include/mach/gpio.h
 create mode 100644 arch/arm/mach-nexell/include/mach/mipi_display.h
 create mode 100644 arch/arm/mach-nexell/include/mach/nexell.h
 create mode 100644 arch/arm/mach-nexell/include/mach/nx_gpio.h
 create mode 100644 arch/arm/mach-nexell/include/mach/reset.h
 create mode 100644 arch/arm/mach-nexell/include/mach/sec_reg.h
 create mode 100644 arch/arm/mach-nexell/include/mach/tieoff.h

diff --git a/arch/arm/mach-nexell/include/mach/boot0.h 
b/arch/arm/mach-nexell/include/mach/boot0.h
new file mode 100644
index 000..e05c07e
--- /dev/null
+++ b/arch/arm/mach-nexell/include/mach/boot0.h
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0+
+ *
+ * NSIH (Nexell System Information Header) for FriendlyArm nanopi2 board
+ *
+ * The NSIH (first 512 Bytes of u-boot.bin) is necessary for the
+ * 2nd-Bootloader to get information like load address of U-Boot.
+ *
+ * 0x400 must be added to CONFIG_SYS_TEXT_BASE to have the actual load and
+ * start address because 2nd-Bootloader loads with an offset of 0x400
+ * (NSIH + 0x200 bytes are not loaded into RAM).
+ *
+ * It has been tested / is working with the following 2nd-Bootloader:
+ * "BL1 by Nexell V1.0.0-gd551e13 [Built on 2018-01-25 16:58:29]"
+ *
+ * (C) Copyright 2020 Stefan Bosch 
+ */
+
+#ifndef __BOOT0_H
+#define __BOOT0_H
+
+   ARM_VECTORS
+   .space  0x30
+   .word   (_end - _start) + 20 * 1024 /* 0x50: load size
+*   (bin + 20k for DTB) */
+   .space  0x4
+   .word   CONFIG_SYS_TEXT_BASE + 0x400/* 0x58: load address */
+   .word   0x
+   .word   CONFIG_SYS_TEXT_BASE + 0x400/* 0x60: start address */
+   .space  0x198
+   .byte   'N' /* 0x1FC: "NSIH" signature */
+   .byte   'S'
+   .byte   'I'
+   .byte   'H'
+
+   /* The NSIH + 0x200 bytes are omitted by the 2nd-Bootloader */
+   .space  0x200
+_start:
+   ARM_VECTORS
+
+#endif /* __BOOT0_H */
diff --git a/arch/arm/mach-nexell/include/mach/clk.h 
b/arch/arm/mach-nexell/include/mach/clk.h
new file mode 100644
index 000..cc5589a
--- /dev/null
+++ b/arch/arm/mach-nexell/include/mach/clk.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0+
+ *
+ * (C) Copyright 2016 Nexell
+ * Hyunseok, Jung 
+ */
+
+#ifndef __ASM_ARM_ARCH_CLK_H_
+#define __ASM_ARM_ARCH_CLK_H_
+
+struct clk {
+   unsigned long rate;
+};
+
+void clk_init(void);
+
+struct clk *clk_get(const char *id);
+void clk_put(struct clk *clk);
+unsigned long clk_get_rate(struct clk *clk);
+long clk_round_rate(struct clk *clk, unsigned long rate);
+int clk_set_rate(struct clk *clk, unsigned long rate);
+int clk_enable(struct clk *clk);
+void clk_disable(struct clk *clk);
+
+#endif
diff --git a/arch/arm/mach-nexell/include/mach/display.h 
b/arch/arm/mach-nexell/include/mach/display.h
new file mode 100644
index 000..b167e63
--- /dev/null
+++ b/arch/arm/mach-nexell/include/mach/display.h
@@ -0,0 +1,273 @@
+/* SPDX-License-Identifier: GPL-2.0+
+ *
+ * Copyright (C) 2016  Nexell Co., Ltd.
+ *
+ * Author: junghyun, kim 
+ */
+
+#ifndef _NX__DISPLAY_H_
+#define _NX__DISPLAY_H_
+
+#defineDP_PLANS_NUM3
+
+/* the display output format. */
+#defineDPC_FORMAT_RGB555   0  /* RGB555 Format */
+#defineDPC_FORMAT_RGB565   1  /* RGB565 Format */
+#defineDPC_FORMAT_RGB666   2  /* RGB666 Format */
+#define

[PATCH v3 00/14] arm: add support for SoC S5P4418

2020-06-29 Thread Stefan Bosch


This patch adds support for SAMSUNG's/NEXELL's ARM Cortex-A9 based
S5P4418 SoC, especially FriendlyARM's NanoPi2 and NanoPC-T2 boards.
It is based on the following FriendlyARM's U-Boot version:
https://github.com/friendlyarm/u-boot/tree/nanopi2-v2016.01.

Main changes in relation to nanopi2-v2016.01:
- Cosmetic changes due to patman warnings/errors.
- MMC and Video drivers changed to DM.
- Configs reworked (e.g. "CONFIG_..." moved from s5p4418_nanopi2.h
  to s5p4418_nanopi2_defconfig)
- SPL related files are not included.
- MACH_TYPE_S5P4418 is not defined/used anymore.
- arch/arm/mach-nexell/include/mach/boot0.h added to generate the NSIH
  (Nexell System Information Header), substitudes tools/nexell.
- board/s5p4418/ renamed to board/friendlyarm/
- Only the NanoPi2 and NanoPC-T2 boards are supported yet because I
  do only have the NanoPC-T2 board to test the code (this board uses
  the NanoPi2 code).
- USB is not supported yet.
- pinctrl-driver/dt is used for mmc and i2c now instead of configuring
  the I/O-pins in the drivers.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
  possible (and similar).
- livetree API (dev_read_...) is used instead of fdt one (fdt...).

The patch-series has been checked by buildman (all arm boards and two
m68k boards = M5235EVB):
  buildman --step 0 -b master arm
  buildman --step 0 -b master M5235EVB
There have been no new warnings or errors.

Changes in v3:
- arch/arm/mach-nexell/Kconfig: "NEXELL_COMMON" removed, has not been
  used at all. NEXELL_ARMV7_COMMON and NEXELL_ARMV8_COMMON removed,
  has been used only in the Kconfig at ARCH_S5P4418 and ARCH_S5P6818.
  Used "select ..."-statements moved appropriately.
  Missing helps added.
- arch/arm/mach-nexell/timer.c: '#include ' inserted because
  it has been removed from common.h.
- '#ifdef...' changed to 'if (IS_ENABLED(CONFIG...))' where possible
  because of appropriate warnings of patman.
- Changed to livetree API as proposed by patman:
  fdtdec_get_int() --> dev_read_s32_default()
  fdt_getprop() --> dev_read_string()
- pinctrl-driver/dt is used now instead of configuring the i2c I/O-pins
  in the i2c-driver.
- drivers/i2c/nx_i2c.c: '#include ' inserted because it has been
  removed from common.h.
- Changed to livetree API as proposed by patman:
  fdtdec_get_int() --> dev_read_s32_default()
- nexell_dw_mmc_dm.c renamed (back) to nexell_dw_mmc.c
- pinctrl-driver/dt is used now instead of configuring the mmc I/O-pins
  in the mmc-driver.
- nexell_dwmmc_ofdata_to_platdata() reworked, i.e. valid default values
  are used now (where possible) and the appropriate if-blocks have
  been removed.
- "nexell," removed from dt-properties, e.g. "nexell,bus-width" changed
  to "bus-width".
- new dt-property "mmcboost" is used now instead of "CONFIG_BOOST_MMC"
  which was not defined anywhere.
- Boot error "Loading Environment from MMC... *** Warning - No block
  device, using default environment" after updating local repository.
  Bugfix in drivers/mmc/nexell_dw_mmc.c: "#include " changed to
  "#include ". This Bug showed up now because of the
  commit "dm: clk: add stub when CONFIG_CLK is deactivated" where
  include/clk.h has been changed.
- drivers/mmc/nexell_dw_mmc.c: '#include ' inserted because it
  has been removed from common.h.
- Kconfig: Missing helps added.
- Changed to livetree API as proposed by patman:
  fdt_stringlist_count() --> dev_read_string_count()
  fdt_stringlist_get() --> dev_read_string_index()
  fdtdec_get_int() --> dev_read_s32_default()
- doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt added.
- Handling of Configs for LCD backlight control reworked because (among
  others) not setting CONFIG_S5P4418_ONEWIRE and/or CONFIG_PWM_NX has
  caused errors when compiling board/friendlyarm/nanopi2/onewire.c.
- pwm.h: () around macro argument x added to avoid precedence issues.
- drivers/video/nexell/s5pxx18_dp_hdmi.c: '#include ' and
  '#include ' inserted because it has been removed from
  common.h.
- drivers/video/nexell_display.c: '#include ' inserted because
  '#include ' (includes command.h) has been removed from common.h.
- Changed to livetree API as proposed by patman:
  fdtdec_get_int() --> ofnode_read_s32_default()
  for (node = ...) --> ofnode_for_each_subnode()
  fdt_get_name() --> ofnode_get_name()
  fdt_getprop() --> dev_read_string()
- nx_display_probe() removed, nx_display_dev_probe_uclass() renamed to
  nx_display_probe().
- dts: pinctrl is supported now, therefore s5p4418-pinctrl.dtsi added,
  mmc- and i2c-entries extended appropriately. New mmc-property
  "mmcboost" added.
- Handling of Configs for LCD backlight control reworked because (among
  others) not setting CONFIG_S5P4418_ONEWIRE and/or CONFIG_PWM_NX has
  caused errors when compiling board/friendlyarm/nanopi2/onewire.c.
- arch/arm/cpu/armv7/s5p4418/cpu.c: '#include ' inserted
  because it has been removed from common.h.
- board/friendlyarm/nanopi2/board.c: Several includes inserted because
  some 

[PATCH v3 02/14] arm: add mach-nexell (all files except header files)

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- SPL not supported yet --> no spl-directory in arch/arm/mach-nexell.
  Appropriate line in Makefile removed.
- clock.c: 'section(".data")' added to declaration of clk_periphs[] and
  core_hz.
- Kconfig: Changes to have a structure like in mach-bcm283x/Kconfig,
  e.g. "config ..." entries moved from other Kconfig.
- timer.c: 'section(".data")' added to declaration of timestamp and
  lastdec.
- arch/arm/mach-nexell/serial.c removed because this is for the UARTs
  of the S5P6818 SoC which is not supported yet. S5P4418 UARTs are
  different, here the (existing) PL011-code is used.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
  possible (and similar).

Signed-off-by: Stefan Bosch 
---

Changes in v3:
- arch/arm/mach-nexell/Kconfig: "NEXELL_COMMON" removed, has not been
  used at all. NEXELL_ARMV7_COMMON and NEXELL_ARMV8_COMMON removed,
  has been used only in the Kconfig at ARCH_S5P4418 and ARCH_S5P6818.
  Used "select ..."-statements moved appropriately.
  Missing helps added.
- arch/arm/mach-nexell/timer.c: '#include ' inserted because
  it has been removed from common.h.
- '#ifdef...' changed to 'if (IS_ENABLED(CONFIG...))' where possible
  because of appropriate warnings of patman.

Changes in v2:
- arch/arm/mach-nexell/serial.c removed because this is for the UARTs
  of the S5P6818 SoC which is not supported yet. S5P4418 UARTs are
  different, here the (existing) PL011-code is used.
- line '... += spl/' in in arch/arm/mach-nexell/Makefile deleted, this
  change has already been stated in the commit message but was missing
  nethertheless.

 arch/arm/Kconfig  |   7 +
 arch/arm/Makefile |   1 +
 arch/arm/mach-nexell/Kconfig  |  58 +++
 arch/arm/mach-nexell/Makefile |  13 +
 arch/arm/mach-nexell/clock.c  | 869 ++
 arch/arm/mach-nexell/cmd_boot_linux.c | 144 ++
 arch/arm/mach-nexell/config.mk|  11 +
 arch/arm/mach-nexell/nx_gpio.c| 352 ++
 arch/arm/mach-nexell/nx_sec_reg.c |  82 
 arch/arm/mach-nexell/reg-call.S   |  23 +
 arch/arm/mach-nexell/reset.c  |  33 ++
 arch/arm/mach-nexell/tieoff.c | 107 +
 arch/arm/mach-nexell/timer.c  | 299 
 13 files changed, 1999 insertions(+)
 create mode 100644 arch/arm/mach-nexell/Kconfig
 create mode 100644 arch/arm/mach-nexell/Makefile
 create mode 100644 arch/arm/mach-nexell/clock.c
 create mode 100644 arch/arm/mach-nexell/cmd_boot_linux.c
 create mode 100644 arch/arm/mach-nexell/config.mk
 create mode 100644 arch/arm/mach-nexell/nx_gpio.c
 create mode 100644 arch/arm/mach-nexell/nx_sec_reg.c
 create mode 100644 arch/arm/mach-nexell/reg-call.S
 create mode 100644 arch/arm/mach-nexell/reset.c
 create mode 100644 arch/arm/mach-nexell/tieoff.c
 create mode 100644 arch/arm/mach-nexell/timer.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index edc9e38..17a0cb5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -901,6 +901,11 @@ config ARCH_MX5
select CPU_V7A
imply MXC_GPIO
 
+config ARCH_NEXELL
+   bool "Nexell S5P4418/S5P6818 SoC"
+   select ENABLE_ARM_SOC_BOOT0_HOOK
+   select DM
+
 config ARCH_OWL
bool "Actions Semi OWL SoCs"
select DM
@@ -1858,6 +1863,8 @@ source "arch/arm/cpu/armv8/Kconfig"
 
 source "arch/arm/mach-imx/Kconfig"
 
+source "arch/arm/mach-nexell/Kconfig"
+
 source "board/bosch/shc/Kconfig"
 source "board/bosch/guardian/Kconfig"
 source "board/CarMediaLab/flea3/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 94eb50b..b9cc985 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -65,6 +65,7 @@ machine-$(CONFIG_ARCH_LPC32XX)+= lpc32xx
 machine-$(CONFIG_ARCH_MEDIATEK)+= mediatek
 machine-$(CONFIG_ARCH_MESON)   += meson
 machine-$(CONFIG_ARCH_MVEBU)   += mvebu
+machine-$(CONFIG_ARCH_NEXELL)  += nexell
 machine-$(CONFIG_ARCH_OMAP2PLUS)   += omap2
 machine-$(CONFIG_ARCH_ORION5X) += orion5x
 machine-$(CONFIG_ARCH_OWL) += owl
diff --git a/arch/arm/mach-nexell/Kconfig b/arch/arm/mach-nexell/Kconfig
new file mode 100644
index 000..ffa4d48
--- /dev/null
+++ b/arch/arm/mach-nexell/Kconfig
@@ -0,0 +1,58 @@
+if ARCH_NEXELL
+
+config ARCH_S5P4418
+   bool "Nexell S5P4418 SoC"
+   select CPU_V7A
+   select OF_CONTROL
+   select OF_SEPARATE
+   select NX_GPIO
+   select PL011_SERIAL
+   select PL011_SERIAL_FLUSH_ON_INIT
+   help
+ Enable support for Nexell S5P4418 SoC.
+
+config ARCH_S5P6818
+   bool "Nexell S5P6818 SoC"
+   select ARM64
+   select ARMV8_MULTIENTRY
+   help
+ Enable support for Nexell S5P6818 SoC.
+
+menu "Nexell S5P4418/S5P6818"
+   depends on ARCH_NEXELL
+
+choice
+   prompt "Nexell S5P4418/S5P6818 board select"
+   optional
+
+config TARGET_NANOPI2
+   bool 

[PATCH v3 03/14] gpio: add nexell driver

2020-06-29 Thread Stefan Bosch
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- livetree API (dev_read_...) is used instead of fdt one (fdt...).

Signed-off-by: Stefan Bosch 
---

Changes in v3:
- Changed to livetree API as proposed by patman:
  fdtdec_get_int() --> dev_read_s32_default()
  fdt_getprop() --> dev_read_string()

Changes in v2:
- commit "i2c: mmc: add nexell driver (gpio, i2c, mmc, pwm)" splitted
  into separate commits for gpio, i2c, mmc, pwm.
- cosmetic: line "obj-$(CONFIG_NX_GPIO) += nx_gpio.o" in
  drivers/gpio/Makefile moved up.

 drivers/gpio/Kconfig   |   9 ++
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/nx_gpio.c | 250 +
 3 files changed, 260 insertions(+)
 create mode 100644 drivers/gpio/nx_gpio.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d87f6cc..921d1e2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -438,4 +438,13 @@ config MT7621_GPIO
help
  Say yes here to support MediaTek MT7621 compatible GPIOs.
 
+config NX_GPIO
+   bool "Nexell GPIO driver"
+   depends on DM_GPIO
+   help
+ Support GPIO access on Nexell SoCs. The GPIOs are arranged into
+ a number of banks (different for each SoC type) each with 32 GPIOs.
+ The GPIOs for a device are defined in the device tree with one node
+ for each bank.
+
 endmenu
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 7638259..334c5f2 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -64,4 +64,5 @@ obj-$(CONFIG_$(SPL_)PCF8575_GPIO) += pcf8575_gpio.o
 obj-$(CONFIG_PM8916_GPIO)  += pm8916_gpio.o
 obj-$(CONFIG_MT7621_GPIO)  += mt7621_gpio.o
 obj-$(CONFIG_MSCC_SGPIO)   += mscc_sgpio.o
+obj-$(CONFIG_NX_GPIO)  += nx_gpio.o
 obj-$(CONFIG_SIFIVE_GPIO)  += sifive-gpio.o
diff --git a/drivers/gpio/nx_gpio.c b/drivers/gpio/nx_gpio.c
new file mode 100644
index 000..5ec73c4
--- /dev/null
+++ b/drivers/gpio/nx_gpio.c
@@ -0,0 +1,250 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2016 Nexell
+ * DeokJin, Lee 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct nx_gpio_regs {
+   u32 data;   /* Data register */
+   u32 outputenb;  /* Output Enable register */
+   u32 detmode[2]; /* Detect Mode Register */
+   u32 intenb; /* Interrupt Enable Register */
+   u32 det;/* Event Detect Register */
+   u32 pad;/* Pad Status Register */
+};
+
+struct nx_alive_gpio_regs {
+   u32 pwrgate;/* Power Gating Register */
+   u32 reserved0[28];  /* Reserved0 */
+   u32 outputenb_reset;/* Alive GPIO Output Enable Reset Register */
+   u32 outputenb;  /* Alive GPIO Output Enable Register */
+   u32 outputenb_read; /* Alive GPIO Output Read Register */
+   u32 reserved1[3];   /* Reserved1 */
+   u32 pad_reset;  /* Alive GPIO Output Reset Register */
+   u32 data;   /* Alive GPIO Output Register */
+   u32 pad_read;   /* Alive GPIO Pad Read Register */
+   u32 reserved2[33];  /* Reserved2 */
+   u32 pad;/* Alive GPIO Input Value Register */
+};
+
+struct nx_gpio_platdata {
+   void *regs;
+   int gpio_count;
+   const char *bank_name;
+};
+
+static int nx_alive_gpio_is_check(struct udevice *dev)
+{
+   struct nx_gpio_platdata *plat = dev_get_platdata(dev);
+   const char *bank_name = plat->bank_name;
+
+   if (!strcmp(bank_name, "gpio_alv"))
+   return 1;
+
+   return 0;
+}
+
+static int nx_alive_gpio_direction_input(struct udevice *dev, unsigned int pin)
+{
+   struct nx_gpio_platdata *plat = dev_get_platdata(dev);
+   struct nx_alive_gpio_regs *const regs = plat->regs;
+
+   setbits_le32(>outputenb_reset, 1 << pin);
+
+   return 0;
+}
+
+static int nx_alive_gpio_direction_output(struct udevice *dev, unsigned int 
pin,
+ int val)
+{
+   struct nx_gpio_platdata *plat = dev_get_platdata(dev);
+   struct nx_alive_gpio_regs *const regs = plat->regs;
+
+   if (val)
+   setbits_le32(>data, 1 << pin);
+   else
+   setbits_le32(>pad_reset, 1 << pin);
+
+   setbits_le32(>outputenb, 1 << pin);
+
+   return 0;
+}
+
+static int nx_alive_gpio_get_value(struct udevice *dev, unsigned int pin)
+{
+   struct nx_gpio_platdata *plat = dev_get_platdata(dev);
+   struct nx_alive_gpio_regs *const regs = plat->regs;
+   unsigned int mask = 1UL << pin;
+   unsigned int value;
+
+   value = (readl(>pad_read) & mask) >> pin;
+
+   return value;
+}
+
+static int nx_alive_gpio_set_value(struct udevice *dev, unsigned int pin,
+  int val)
+{
+   struct nx_gpio_platdata *plat = dev_get_platdata(dev);
+   struct 

Re: [PATCH 1/2] vboot: add support for multiple required keys

2020-06-29 Thread Simon Glass
Hi Thirupathaiah,


On Mon, 29 Jun 2020 at 11:26, Simon Glass  wrote:
>
> Hi Thirupathaiah,
>
> On Thu, 25 Jun 2020 at 09:51, Thirupathaiah Annapureddy
>  wrote:
> >
> > Currently Verified Boot fails if there is a signature verification failure
> > using required key in U-boot DTB. This patch adds support for multiple
> > required keys. This means if verified boot passes with one of the required
> > keys, u-boot will continue the OS hand off.
> >
> > There was a prior attempt to resolve this with the following patch:
> > https://lists.denx.de/pipermail/u-boot/2019-April/366047.html
> > The above patch was failing "make tests".
> >
> > Signed-off-by: Thirupathaiah Annapureddy 
> > ---
> >  common/image-fit-sig.c | 12 +++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)

One more thing...this patch is changing the policy.

I think we need a new string property in the DTB alongside the
'required' properly, that indicates whether the image must be signed
with all required keys, or just one.

Regards,
Simon


Re: [PATCH 1/2] vboot: add support for multiple required keys

2020-06-29 Thread Simon Glass
Hi Thirupathaiah,

On Thu, 25 Jun 2020 at 09:51, Thirupathaiah Annapureddy
 wrote:
>
> Currently Verified Boot fails if there is a signature verification failure
> using required key in U-boot DTB. This patch adds support for multiple
> required keys. This means if verified boot passes with one of the required
> keys, u-boot will continue the OS hand off.
>
> There was a prior attempt to resolve this with the following patch:
> https://lists.denx.de/pipermail/u-boot/2019-April/366047.html
> The above patch was failing "make tests".
>
> Signed-off-by: Thirupathaiah Annapureddy 
> ---
>  common/image-fit-sig.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/common/image-fit-sig.c b/common/image-fit-sig.c
> index cc1967109e..4d25d4c541 100644
> --- a/common/image-fit-sig.c
> +++ b/common/image-fit-sig.c
> @@ -416,6 +416,8 @@ int fit_config_verify_required_sigs(const void *fit, int 
> conf_noffset,
>  {
> int noffset;
> int sig_node;
> +   int verified = 0;

Can this be a bool?

> +   int reqd_sigs = 0;
>
> /* Work out what we need to verify */
> sig_node = fdt_subnode_offset(sig_blob, 0, FIT_SIG_NODENAME);
> @@ -433,15 +435,23 @@ int fit_config_verify_required_sigs(const void *fit, 
> int conf_noffset,
>NULL);
> if (!required || strcmp(required, "conf"))
> continue;
> +
> +   reqd_sigs++;
> +
> ret = fit_config_verify_sig(fit, conf_noffset, sig_blob,
> noffset);
> if (ret) {
> printf("Failed to verify required signature '%s'\n",
>fit_get_name(sig_blob, noffset, NULL));

This message is confusing if we then decide that things are OK. I
think it would be better to change the message to a positive "Verified
required signatured xxx" if !ret

> -   return ret;
> +   } else {
> +   verified = 1;
> +   break;
> }
> }
>
> +   if (reqd_sigs && !verified)
> +   return -EPERM;

This needs a message, something like "No required signatures were verified"

and then list them in a for() loop.

> +
> return 0;
>  }
>
> --
> 2.17.1
>

Regards,
Simon


Re: [PATCH v3 12/15] board: ns3: limit U-boot relocation within 16MB memory

2020-06-29 Thread Simon Glass
Hi Rayagonda,

On Fri, 26 Jun 2020 at 04:21, Rayagonda Kokatanur
 wrote:
>
> On Fri, Jun 26, 2020 at 6:42 AM Simon Glass  wrote:
> >
> > On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur
> >  wrote:
> > >
> > > From: Bharat Kumar Reddy Gooty 
> > >
> > > By default re-location happens to higher address of DDR,
> >
> > relocation happens to a higher address
>
> Thank you, will fix it.
> >
> > > i.e, DDR start + DDR size.
> > >
> > > Limit re-location to happen within 16MB memory,
> > > start 0xFF00_ and end 0x1__
> >
> > Please add the motivation for this patch. Why?
>
> We use u-boot to collect the ramdump. We are restricting the u-boot to
> use only 16MB. So that we can reserve only 16MB DDR

U-Boot

So you are wanting to leave most of the memory alone so you can check
it for this?

OK that's the info needed in your commit message.

Regards,
Simon


Re: [PATCH 1/1] crypto/fsl: unused value in caam_hash_update()

2020-06-29 Thread Simon Glass
On Sat, 27 Jun 2020 at 02:14, Heinrich Schuchardt  wrote:
>
> The value 0 assigned to final is overwritten before ever being used.
>
> Remove the assignment.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/crypto/fsl/fsl_hash.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH 1/1] fs: error handling in do_load()

2020-06-29 Thread Simon Glass
On Sat, 27 Jun 2020 at 02:24, Heinrich Schuchardt  wrote:
>
> If a file cannot be loaded, show an error message.
> Set the EFI boot device only after successfully loading a file.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  fs/fs.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>

Reviewed-by: Simon Glass 

> diff --git a/fs/fs.c b/fs/fs.c
> index ad4caaeb1e..12fa5a6489 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -715,15 +715,18 @@ int do_load(struct cmd_tbl *cmdtp, int flag, int argc, 
> char *const argv[],
> else
> pos = 0;
>
> -#ifdef CONFIG_CMD_BOOTEFI
> -   efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
> -   (argc > 4) ? argv[4] : "");
> -#endif
> time = get_timer(0);
> ret = _fs_read(filename, addr, pos, bytes, 1, _read);
> time = get_timer(time);
> -   if (ret < 0)
> +   if (ret < 0) {
> +   printf("Failed to load '%s'\n", filename);
> return 1;
> +   }
> +
> +#ifdef CONFIG_CMD_BOOTEFI
> +   efi_set_bootdev(argv[1], (argc > 2) ? argv[2] : "",
> +   (argc > 4) ? argv[4] : "");
> +#endif

Can this use if() instead?

>
> printf("%llu bytes read in %lu ms", len_read, time);
> if (time > 0) {
> --
> 2.27.0
>

Regards,
Simon


Re: [PATCH] cmd: add a panic command

2020-06-29 Thread Simon Glass
On Fri, 26 Jun 2020 at 05:36, Heiko Stuebner  wrote:
>
> From: Heiko Stuebner 
>
> Even in boot scripts it may be needed to "panic" when all options
> are exhausted and the device specification specifies hanging
> instead of resetting the board.
>
> So add a new panic command that just wraps around the core panic
> call in uboot and can take an optional message.

U-Boot

>
> Signed-off-by: Heiko Stuebner 
> ---
>  cmd/Makefile |  1 +
>  cmd/panic.c  | 22 ++
>  2 files changed, 23 insertions(+)
>  create mode 100644 cmd/panic.c

Reviewed-by: Simon Glass 

nit below

>
> diff --git a/cmd/Makefile b/cmd/Makefile
> index ac843b4b16..027fa9083a 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -8,6 +8,7 @@ ifndef CONFIG_SPL_BUILD
>  obj-y += boot.o
>  obj-$(CONFIG_CMD_BOOTM) += bootm.o
>  obj-y += help.o
> +obj-y += panic.o
>  obj-y += version.o
>
>  # command
> diff --git a/cmd/panic.c b/cmd/panic.c
> new file mode 100644
> index 00..696b4c73a3
> --- /dev/null
> +++ b/cmd/panic.c
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2020 Theobroma Systems Design und Consulting GmbH
> + */
> +
> +#include 
> +#include 
> +
> +static int do_panic(cmd_tbl_t *cmdtp, int flag, int argc,
> +   char * const argv[])
> +{
> +   char *text = (argc < 2) ? "" : argv[1];
> +
> +   panic(text);

blank line here


> +   return CMD_RET_SUCCESS;
> +}
> +
> +U_BOOT_CMD(
> +   panic,  2,  1,  do_panic,
> +   "Panic with optional message",
> +   "[message]"
> +);
> --
> 2.26.2
>


Re: [PATCH 1/1] gitlab: show skipped Python tests

2020-06-29 Thread Simon Glass
Hi Tom,

On Fri, 26 Jun 2020 at 14:16, Tom Rini  wrote:
>
> On Wed, Jun 24, 2020 at 02:04:37PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 24 Jun 2020 at 09:53, Tom Rini  wrote:
> > >
> > > On Wed, Jun 24, 2020 at 09:17:51AM -0600, Simon Glass wrote:
> > > > Hi Heinrich,
> > > >
> > > > On Wed, 24 Jun 2020 at 07:56, Heinrich Schuchardt  
> > > > wrote:
> > > > >
> > > > > On 24.06.20 15:49, Simon Glass wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, 22 Jun 2020 at 12:46, Tom Rini  wrote:
> > > > > >>
> > > > > >> On Mon, Jun 22, 2020 at 12:23:35PM -0600, Simon Glass wrote:
> > > > > >>> Hi Heinrich,
> > > > > >>>
> > > > > >>> On Mon, 22 Jun 2020 at 10:40, Heinrich Schuchardt 
> > > > > >>>  wrote:
> > > > > 
> > > > >  On 22.06.20 18:17, Simon Glass wrote:
> > > > > > Hi Heinrich,
> > > > > >
> > > > > > On Mon, 22 Jun 2020 at 10:07, Heinrich Schuchardt 
> > > > > >  wrote:
> > > > > >>
> > > > > >> Call pytest3 with argument -ra to display reason why Python 
> > > > > >> tests are
> > > > > >> skipped.
> > > > > >>
> > > > > >> Signed-off-by: Heinrich Schuchardt 
> > > > > >> ---
> > > > > >>  .gitlab-ci.yml | 2 +-
> > > > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >>
> > > > > >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > > > >> index f2e491c117..f53098ea5f 100644
> > > > > >> --- a/.gitlab-ci.yml
> > > > > >> +++ b/.gitlab-ci.yml
> > > > > >> @@ -46,7 +46,7 @@ stages:
> > > > > >>  # "${var:+"-k $var"}" expands to "" if $var is empty, "-k 
> > > > > >> $var" if not
> > > > > >>  - export 
> > > > > >> PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
> > > > > >>export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
> > > > > >> -  ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
> > > > > >> +  ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
> > > > > >>  ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
> > > > > >>  --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
> > > > > >
> > > > > > Do you have a link showing the current output with this patch?
> > > > > 
> > > > >  Hello Simon,
> > > > > 
> > > > >  here is an example output:
> > > > > 
> > > > >  https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112385
> > > > > >>>
> > > > > >>> That's what I was afraid of. The skip output is more than the 
> > > > > >>> normal
> > > > > >>> output, and if we don't intend to fix it, I'd rather not have
> > > > > >>> unactionable warnings in the output.
> > > > > >>>
> > > > > >>> Having said that, we need to enable SPI flash, FPGA and MMC
> > > > > >>> environment tests by the look of it.
> > > > > >>
> > > > > >> On a different note, I think we should look at:
> > > > > >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112376
> > > > > >> and:
> > > > > >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112380
> > > > > >>
> > > > > >> as it shows that the reason we probably skip the 
> > > > > >> test_fs/test_mkdir.py
> > > > > >> tests is that since board is literal, we don't match sandbox on
> > > > > >> sandbox_flattree.  That answers one outstanding question about why 
> > > > > >> we
> > > > > >> skip some tests and not others at least.
> > > > > >
> > > > > > Hmm yes.
> > > > > >
> > > > > > It is definitely good to have this output so we can figure out what
> > > > > > should not be skipped.
> > > > > >
> > > > > > But outputting things which we know should be skipped just means we
> > > > > > won't notice those that are not supposed to be skipped. How do we
> > > > > > handle that?
> > > > > >
> > > > > > Regards,
> > > > > > Simon
> > > > > >
> > > > > If you have a lines like:
> > > > >
> > > > > .config feature "cmd_fpga_loadbp" not enabled
> > > > > board "qemu_arm64" not supported
> > > > >
> > > > > you know the test is skipped due to configuration.
> > > >
> > > > OK then can we avoid printing this useless information by default?
> > >
> > > It's not useless information.  It's what I pointed to in another part of
> > > the thread as to why we're skipping tests we didn't expect to skip.
> >
> > I thought these ones were intended to be skipped? I'm perhaps just
> > confused about what is going on here.
>
> We have a number of "sandbox" targets which should be running the FS
> tests, but do not.  Figuring out why has been low on my TODO list, but
> is very clear with this extra information.
>
> Still haven't however figured out why we do see this:
> https://travis-ci.org/github/u-boot/u-boot/jobs/702114991 (which is, all
> FS tests run).
>
> > > > > Other messages clearly tell you that something is not correctly set 
> > > > > up:
> > > > >
> > > > > No env__efi_loader_grub_file binary specified in environment
> > > > > got empty parameter set ['env__mmc_dev_config']
> > > >
> > > > OK then this is what we should display.
> > >
> > 

Re: [PATCH] x86: Don't build some unused objects in TPL

2020-06-29 Thread Simon Glass
On Sat, 27 Jun 2020 at 07:10, Bin Meng  wrote:
>
> +Simon,
>
> On Sat, Jun 27, 2020 at 8:00 PM Tom Rini  wrote:
> >
> > In the future if we have separate symbols for DM_SPI_FLASH and
> > SPL_DM_SPI_FLASH we will not always have function declarations available
> > for some DM calls.  This in turn leads to build warnings but not
> > failures as the code isn't used and is discarded at link time.
> > Restructure things to not build code we won't use for TPL anyways.
> >
> > Cc: Bin Meng 
> > Signed-off-by: Tom Rini 
> > ---
> > I ran in to this as part of testing
> > http://patchwork.ozlabs.org/project/uboot/patch/20200604151153.3980-4-zhiqiang@nxp.com/
> > which we do need to bring in.  I think we might be building a lot of
> > codde that's then discarded for TPL builds, but didn't think this is the
> > right place to tackle that in.

Yes we build far too much with TPL at present I think.

> > ---
> >  arch/x86/cpu/apollolake/Makefile | 2 +-
> >  arch/x86/lib/Makefile| 4 +++-
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> >
>
> Reviewed-by: Bin Meng 

Reviewed-by: Simon Glass 


Re: [PATCH v3 1/2] drivers: tee: broadcom: add optee based bnxt fw load driver

2020-06-29 Thread Simon Glass
Hi Rayagonda,

On Sun, 28 Jun 2020 at 21:08, Rayagonda Kokatanur
 wrote:
>
> Hi Simon,
>
> On Fri, Jun 26, 2020 at 6:42 AM Simon Glass  wrote:
> >
> > Hi Rayagonda,
> >
> > On Wed, 10 Jun 2020 at 05:15, Rayagonda Kokatanur
> >  wrote:
> > >
> > > From: Vikas Gupta 
> > >
> > > Add optee based bnxt fw load driver.
> > > bnxt is Broadcom NetXtreme controller Ethernet card.
> > > This driver is used to load bnxt firmware binary using OpTEE.
> > >
> > > Signed-off-by: Vikas Gupta 
> > > Signed-off-by: Rayagonda Kokatanur 
> > > ---
> > > Changes from v2:
> > >  -Address review comments from Simon,
> > >   Remove own return code and use standard error code.
> > >   Take out common lines from different functions and move them
> > >   into common static function.
> > >   Remove include  as its not required.
> > >   Move functions with printf from header file into c file.
> > >
> > >  drivers/tee/Kconfig|   1 +
> > >  drivers/tee/Makefile   |   1 +
> > >  drivers/tee/broadcom/Kconfig   |   7 ++
> > >  drivers/tee/broadcom/Makefile  |   3 +
> > >  drivers/tee/broadcom/chimp_optee.c | 182 +
> > >  include/broadcom/chimp.h   |  16 +++
> > >  6 files changed, 210 insertions(+)
> > >  create mode 100644 drivers/tee/broadcom/Kconfig
> > >  create mode 100644 drivers/tee/broadcom/Makefile
> > >  create mode 100644 drivers/tee/broadcom/chimp_optee.c
> > >  create mode 100644 include/broadcom/chimp.h
> > >
> > > diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
> > > index 5c0c89043f..5ca5a0836c 100644
> > > --- a/drivers/tee/Kconfig
> > > +++ b/drivers/tee/Kconfig
> > > @@ -29,6 +29,7 @@ config SANDBOX_TEE
> > >   "avb" commands.
> > >
> > >  source "drivers/tee/optee/Kconfig"
> > > +source "drivers/tee/broadcom/Kconfig"
> > >
> > >  endmenu
> > >
> > > diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
> > > index f72c68c09f..5c8ffdbce8 100644
> > > --- a/drivers/tee/Makefile
> > > +++ b/drivers/tee/Makefile
> > > @@ -3,3 +3,4 @@
> > >  obj-y += tee-uclass.o
> > >  obj-$(CONFIG_SANDBOX) += sandbox.o
> > >  obj-$(CONFIG_OPTEE) += optee/
> > > +obj-y += broadcom/
> > > diff --git a/drivers/tee/broadcom/Kconfig b/drivers/tee/broadcom/Kconfig
> > > new file mode 100644
> > > index 00..ce95072d4e
> > > --- /dev/null
> > > +++ b/drivers/tee/broadcom/Kconfig
> > > @@ -0,0 +1,7 @@
> > > +config CHIMP_OPTEE
> > > +   bool "Enable secure ChiMP firmware loading"
> > > +   depends on OPTEE
> > > +   default y
> > > +   help
> > > + This driver is used to load bnxt firmware binary using OpTEE.
> > > + bnxt is Broadcom NetXtreme controller Ethernet card.
> > > diff --git a/drivers/tee/broadcom/Makefile b/drivers/tee/broadcom/Makefile
> > > new file mode 100644
> > > index 00..cb3cef16df
> > > --- /dev/null
> > > +++ b/drivers/tee/broadcom/Makefile
> > > @@ -0,0 +1,3 @@
> > > +# SPDX-License-Identifier: GPL-2.0+
> > > +
> > > +obj-y += chimp_optee.o
> > > diff --git a/drivers/tee/broadcom/chimp_optee.c 
> > > b/drivers/tee/broadcom/chimp_optee.c
> > > new file mode 100644
> > > index 00..4ca1b59c6a
> > > --- /dev/null
> > > +++ b/drivers/tee/broadcom/chimp_optee.c
> > > @@ -0,0 +1,182 @@
> > > +// SPDX-License-Identifier: BSD-2-Clause
> > > +/*
> > > + * Copyright 2020 Broadcom.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#ifdef CONFIG_CHIMP_OPTEE
> > > +
> > > +#define CHMIP_BOOT_UUID { 0x6272636D, 0x2019, 0x0716, \
> > > +  { 0x42, 0x43, 0x4D, 0x5F, 0x53, 0x43, 0x48, 0x49 } }
> > > +
> > > +enum {
> > > +   TEE_CHIMP_FASTBOOT = 0,
> > > +   TEE_CHIMP_HEALTH_STATUS,
> > > +   TEE_CHIMP_HANDSHAKE_STATUS,
> > > +} tee_chmip_cmd;
> > > +
> > > +struct bcm_chimp_data {
> > > +   struct udevice *tee;
> > > +   u32 session;
> > > +} chimp_data;
> > > +
> > > +static int get_open_session(struct bcm_chimp_data *b_data)
> > > +{
> > > +   struct udevice *tee = NULL;
> > > +
> > > +   while (!b_data->tee) {
> > > +   const struct tee_optee_ta_uuid uuid = CHMIP_BOOT_UUID;
> > > +   struct tee_open_session_arg arg;
> > > +   int rc;
> > > +
> > > +   tee = tee_find_device(tee, NULL, NULL, NULL);
> > > +   if (!tee)
> > > +   return -ENODEV;
> > > +
> > > +   memset(, 0, sizeof(arg));
> > > +   tee_optee_ta_uuid_to_octets(arg.uuid, );
> > > +   rc = tee_open_session(tee, , 0, NULL);
> > > +   if (!rc) {
> > > +   b_data->tee = tee;
> > > +   b_data->session = arg.session;
> > > +   }
> > > +   }
> > > +
> >
> > Is this looping forever? Should you return -ETIMEDOUT using
> > get_timer() to check this?
>
> Its not an infinite loop.
> Within the loop we are looking for our device.
> Once all device iteration is over loop will exit or if we 

Re: [PATCH v4 02/14] dtoc: add missing code comments

2020-06-29 Thread Simon Glass
Hi Walter,

On Fri, 26 Jun 2020 at 07:18, Walter Lozano  wrote:
>
> Hi Simon,
>
> On 25/6/20 22:42, Simon Glass wrote:
> > On Wed, 24 Jun 2020 at 22:10, Walter Lozano  
> > wrote:
> >> Add missing information about internal class members in order to make
> >> the code easier to follow.
> >>
> >> Signed-off-by: Walter Lozano 
> >> ---
> >>
> >>   tools/dtoc/dtb_platdata.py | 3 +++
> >>   1 file changed, 3 insertions(+)
> >>
> > Reviewed-by: Simon Glass 
> >
> > BTW if there was a review tag from last version, please add it to your 
> > commit.
>
>
> Thanks for pointing that, I'll take you advice for those commit that
> doesn't change at all. Also thank you for all the time you spent
> reviewing this series and sharing suggestions.

You're welcome. It's a great improvement to of-platdata! You can add
it the tag unless you make a major change to a commit.

Regards,
Simon


Re: [PATCH U-BOOT v3 00/30] PLEASE TEST fs: btrfs: Re-implement btrfs support using code from btrfs-progs

2020-06-29 Thread Simon Glass
Hi,

On Fri, 26 Jun 2020 at 07:36, Tom Rini  wrote:
>
> On Thu, Jun 25, 2020 at 07:43:20PM -0600, Simon Glass wrote:
> > Hi Marek,
> >
> > On Wed, 24 Jun 2020 at 10:03, Marek Behún  wrote:
> > >
> > > Hello,
> > >
> > > this is a cleaned up version of Qu's patches that reimplements U-Boot's
> > > btrfs driver with code from btrfs-progs.
> > >
> > > I have tested this series, found and corrected one bug (failure when
> > > accesing files via symlinks), and it looks it is working now, but I
> > > would like more people to do some testing.
> > >
> > > There are a lot of checkpatch warnings and errors left, I shall fix
> > > this in the future.
> > >
> > > Marek
> >
> > Please can you add a test for this one? See fs-test.sh
>
> Not more fs-test.sh tests, test/py/tests/test_fs/ tests please, thanks!

That's good news, I hadn't noticed the conversion from shell!

Regards,
Simon


[PATCH v6 4/4] usb: xhci: Add reset controller support

2020-06-29 Thread Nicolas Saenz Julienne
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.

Signed-off-by: Nicolas Saenz Julienne 

---
Changes since v5:
 - Take !CONFIG_IS_ENABLED(DM_RESET) into account

 drivers/usb/host/xhci-mem.c |  2 ++
 drivers/usb/host/xhci.c | 33 +
 include/usb/xhci.h  |  2 ++
 3 files changed, 37 insertions(+)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index f446520528..108f4bd8cf 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -180,6 +180,8 @@ void xhci_cleanup(struct xhci_ctrl *ctrl)
xhci_free_virt_devices(ctrl);
free(ctrl->erst.entries);
free(ctrl->dcbaa);
+   if (reset_valid(>reset))
+   reset_free(>reset);
memset(ctrl, '\0', sizeof(struct xhci_ctrl));
 }
 
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ebd2954571..e252964d0d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -190,6 +190,35 @@ static int xhci_start(struct xhci_hcor *hcor)
return ret;
 }
 
+/**
+ * Resets XHCI Hardware
+ *
+ * @param ctrl pointer to host controller
+ * @return 0 if OK, or a negative error code.
+ */
+static int xhci_reset_hw(struct xhci_ctrl *ctrl)
+{
+   int ret;
+
+   ret = reset_get_by_index(ctrl->dev, 0, >reset);
+   if (ret && ret != -ENOENT && ret != -ENOTSUPP) {
+   dev_err(ctrl->dev, "failed to get reset\n");
+   return ret;
+   }
+
+   if (reset_valid(>reset)) {
+   ret = reset_assert(>reset);
+   if (ret)
+   return ret;
+
+   ret = reset_deassert(>reset);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
 /**
  * Resets the XHCI Controller
  *
@@ -1508,6 +1537,10 @@ int xhci_register(struct udevice *dev, struct xhci_hccr 
*hccr,
 
ctrl->dev = dev;
 
+   ret = xhci_reset_hw(ctrl);
+   if (ret)
+   goto err;
+
/*
 * XHCI needs to issue a Address device command to setup
 * proper device context structures, before it can interact
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index 1170c0ac69..7d34103fd5 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -16,6 +16,7 @@
 #ifndef HOST_XHCI_H_
 #define HOST_XHCI_H_
 
+#include 
 #include 
 #include 
 #include 
@@ -1209,6 +1210,7 @@ struct xhci_ctrl {
 #if CONFIG_IS_ENABLED(DM_USB)
struct udevice *dev;
 #endif
+   struct reset_ctl reset;
struct xhci_hccr *hccr; /* R/O registers, not need for volatile */
struct xhci_hcor *hcor;
struct xhci_doorbell_array *dba;
-- 
2.27.0



[PATCH v6 3/4] configs: Enable support for reset controllers on RPi4

2020-06-29 Thread Nicolas Saenz Julienne
This is required in order to access the reset controller used to
initialize the board's xHCI chip.

Signed-off-by: Nicolas Saenz Julienne 
---
 configs/rpi_4_32b_defconfig | 1 +
 configs/rpi_4_defconfig | 1 +
 configs/rpi_arm64_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index b0797373b5..00c8d963ab 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -35,6 +35,7 @@ CONFIG_DM_PCI=y
 CONFIG_PCI_BRCMSTB=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
+CONFIG_DM_RESET=y
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 932b768164..c73eccb61c 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -35,6 +35,7 @@ CONFIG_DM_PCI=y
 CONFIG_PCI_BRCMSTB=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
+CONFIG_DM_RESET=y
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 855afcf1cf..800b51e6f5 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -32,6 +32,7 @@ CONFIG_DM_PCI=y
 CONFIG_PCI_BRCMSTB=y
 CONFIG_PINCTRL=y
 # CONFIG_PINCTRL_GENERIC is not set
+CONFIG_DM_RESET=y
 # CONFIG_REQUIRE_SERIAL_CONSOLE is not set
 CONFIG_USB=y
 CONFIG_DM_USB=y
-- 
2.27.0



[PATCH v6 2/4] reset: Add Raspberry Pi 4 firmware reset controller

2020-06-29 Thread Nicolas Saenz Julienne
Raspberry Pi 4's co-processor controls some of the board's HW
initialization process, but it's up to Linux to trigger it when
relevant. Introduce a reset controller capable of interfacing with
RPi4's co-processor that models these firmware initialization routines as
reset lines.

Signed-off-by: Nicolas Saenz Julienne 
---
 drivers/reset/Kconfig | 10 
 drivers/reset/Makefile|  1 +
 drivers/reset/reset-raspberrypi.c | 60 +++
 .../reset/raspberrypi,firmware-reset.h| 13 
 4 files changed, 84 insertions(+)
 create mode 100644 drivers/reset/reset-raspberrypi.c
 create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 88d3be1593..d02c1522e5 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -148,4 +148,14 @@ config RESET_IMX7
help
  Support for reset controller on i.MX7/8 SoCs.
 
+config RESET_RASPBERRYPI
+   bool "Raspberry Pi 4 Firmware Reset Controller Driver"
+   depends on DM_RESET && ARCH_BCM283X
+   default USB_XHCI_PCI
+   help
+ Raspberry Pi 4's co-processor controls some of the board's HW
+ initialization process, but it's up to Linux to trigger it when
+ relevant. This driver provides a reset controller capable of
+ interfacing with RPi4's co-processor and model these firmware
+ initialization routines as reset lines.
 endmenu
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 0a044d5d8c..be54dae725 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_RESET_MTMIPS) += reset-mtmips.o
 obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_RESET_HISILICON) += reset-hisilicon.o
 obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
+obj-$(CONFIG_RESET_RASPBERRYPI) += reset-raspberrypi.o
diff --git a/drivers/reset/reset-raspberrypi.c 
b/drivers/reset/reset-raspberrypi.c
new file mode 100644
index 00..e2d284e5ac
--- /dev/null
+++ b/drivers/reset/reset-raspberrypi.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Raspberry Pi 4 firmware reset driver
+ *
+ * Copyright (C) 2020 Nicolas Saenz Julienne 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int raspberrypi_reset_request(struct reset_ctl *reset_ctl)
+{
+   if (reset_ctl->id >= RASPBERRYPI_FIRMWARE_RESET_NUM_IDS)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int raspberrypi_reset_free(struct reset_ctl *reset_ctl)
+{
+   return 0;
+}
+
+static int raspberrypi_reset_assert(struct reset_ctl *reset_ctl)
+{
+   switch (reset_ctl->id) {
+   case RASPBERRYPI_FIRMWARE_RESET_ID_USB:
+   bcm2711_notify_vl805_reset();
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+static int raspberrypi_reset_deassert(struct reset_ctl *reset_ctl)
+{
+   return 0;
+}
+
+struct reset_ops raspberrypi_reset_ops = {
+   .request = raspberrypi_reset_request,
+   .rfree = raspberrypi_reset_free,
+   .rst_assert = raspberrypi_reset_assert,
+   .rst_deassert = raspberrypi_reset_deassert,
+};
+
+static const struct udevice_id raspberrypi_reset_ids[] = {
+   { .compatible = "raspberrypi,firmware-reset" },
+   { }
+};
+
+U_BOOT_DRIVER(raspberrypi_reset) = {
+   .name = "raspberrypi-reset",
+   .id = UCLASS_RESET,
+   .of_match = raspberrypi_reset_ids,
+   .ops = _reset_ops,
+};
+
diff --git a/include/dt-bindings/reset/raspberrypi,firmware-reset.h 
b/include/dt-bindings/reset/raspberrypi,firmware-reset.h
new file mode 100644
index 00..1a4f4c7927
--- /dev/null
+++ b/include/dt-bindings/reset/raspberrypi,firmware-reset.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 Nicolas Saenz Julienne
+ * Author: Nicolas Saenz Julienne 
+ */
+
+#ifndef _DT_BINDINGS_RASPBERRYPI_FIRMWARE_RESET_H
+#define _DT_BINDINGS_RASPBERRYPI_FIRMWARE_RESET_H
+
+#define RASPBERRYPI_FIRMWARE_RESET_ID_USB  0
+#define RASPBERRYPI_FIRMWARE_RESET_NUM_IDS 1
+
+#endif
-- 
2.27.0



[PATCH v6 0/4] usb: xhci: Load Raspberry Pi 4 VL805's firmware

2020-06-29 Thread Nicolas Saenz Julienne
Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
loaded explicitly. Earlier versions didn't need that as they where using
an EEPROM for that purpose. This series takes care of setting up the
relevant infrastructure and run the firmware loading routine at the
right moment.

Note that this builds on top of Sylwester Nawrocki's "USB host support
for Raspberry Pi 4 board" series.

This also depends on a DT/bindings patch available on the linux-mailing lists:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2205783.html

Here is the relevant bit for reference/discussion:

 {
   pci@1,0 {
   #address-cells = <3>;
   #size-cells = <2>;
   ranges;

   reg = <0 0 0 0 0>;

   usb@1,0 {
   reg = <0x1 0 0 0 0>;
   resets = < 
RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
   };
   };
};

---

Changes since v5:
 - Properly handle !CONFIG_IS_ENABLED(DM_RESET) in xchi code

Changes since v4:
 - Correct DT PCI topology, I separated the root bridge and controller
   DT nodes
 - Get rid of PCI core patch as not needed with correct DT PCI topology
 - Move reset support to xchi core

Changes since v3:
 - Use reset controller

Changes since v2:
 - Correct comment on patch #1
 - Address Matthias' comments

Changes since v1:
 - Rename function
 - Use callback in xhci-pci.c

Nicolas Saenz Julienne (4):
  arm: rpi: Add function to trigger VL805's firmware load
  reset: Add Raspberry Pi 4 firmware reset controller
  configs: Enable support for reset controllers on RPi4
  usb: xhci: Add reset controller support

 arch/arm/mach-bcm283x/include/mach/mbox.h | 13 
 arch/arm/mach-bcm283x/include/mach/msg.h  |  7 +++
 arch/arm/mach-bcm283x/msg.c   | 46 ++
 configs/rpi_4_32b_defconfig   |  1 +
 configs/rpi_4_defconfig   |  1 +
 configs/rpi_arm64_defconfig   |  1 +
 drivers/reset/Kconfig | 10 
 drivers/reset/Makefile|  1 +
 drivers/reset/reset-raspberrypi.c | 60 +++
 drivers/usb/host/xhci-mem.c   |  2 +
 drivers/usb/host/xhci.c   | 33 ++
 .../reset/raspberrypi,firmware-reset.h| 13 
 include/usb/xhci.h|  2 +
 13 files changed, 190 insertions(+)
 create mode 100644 drivers/reset/reset-raspberrypi.c
 create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h

-- 
2.27.0



[PATCH v6 1/4] arm: rpi: Add function to trigger VL805's firmware load

2020-06-29 Thread Nicolas Saenz Julienne
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.

Signed-off-by: Nicolas Saenz Julienne 

---
Changes since v1:
 - Rename function so it's not mistaken with regular firmware loading

 arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++
 arch/arm/mach-bcm283x/include/mach/msg.h  |  7 
 arch/arm/mach-bcm283x/msg.c   | 46 +++
 3 files changed, 66 insertions(+)

diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h 
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 60e226ce1d..2ae2d3d97c 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -491,6 +491,19 @@ struct bcm2835_mbox_tag_set_palette {
} body;
 };
 
+#define BCM2835_MBOX_TAG_NOTIFY_XHCI_RESET  0x00030058
+
+struct bcm2835_mbox_tag_pci_dev_addr {
+   struct bcm2835_mbox_tag_hdr tag_hdr;
+   union {
+   struct {
+   u32 dev_addr;
+   } req;
+   struct {
+   } resp;
+   } body;
+};
+
 /*
  * Pass a raw u32 message to the VC, and receive a raw u32 back.
  *
diff --git a/arch/arm/mach-bcm283x/include/mach/msg.h 
b/arch/arm/mach-bcm283x/include/mach/msg.h
index 4afb08631b..e45c1bf010 100644
--- a/arch/arm/mach-bcm283x/include/mach/msg.h
+++ b/arch/arm/mach-bcm283x/include/mach/msg.h
@@ -48,4 +48,11 @@ int bcm2835_set_video_params(int *widthp, int *heightp, int 
depth_bpp,
 int pixel_order, int alpha_mode, ulong *fb_basep,
 ulong *fb_sizep, int *pitchp);
 
+/**
+ * bcm2711_load_vl805_firmware() - get vl805's firmware loaded
+ *
+ * @return 0 if OK, -EIO on error
+ */
+int bcm2711_notify_vl805_reset(void);
+
 #endif
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 94b75283f8..347aece3cd 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct msg_set_power_state {
struct bcm2835_mbox_hdr hdr;
@@ -40,6 +41,12 @@ struct msg_setup {
u32 end_tag;
 };
 
+struct msg_notify_vl805_reset {
+   struct bcm2835_mbox_hdr hdr;
+   struct bcm2835_mbox_tag_pci_dev_addr dev_addr;
+   u32 end_tag;
+};
+
 int bcm2835_power_on_module(u32 module)
 {
ALLOC_CACHE_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1);
@@ -151,3 +158,42 @@ int bcm2835_set_video_params(int *widthp, int *heightp, 
int depth_bpp,
 
return 0;
 }
+
+/*
+ * On the Raspberry Pi 4, after a PCI reset, VL805's (the xHCI chip) firmware
+ * may either be loaded directly from an EEPROM or, if not present, by the
+ * SoC's VideoCore. This informs VideoCore that VL805 needs its firmware
+ * loaded.
+ */
+int bcm2711_notify_vl805_reset(void)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset,
+msg_notify_vl805_reset, 1);
+   int ret;
+
+   BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset);
+   BCM2835_MBOX_INIT_TAG(_notify_vl805_reset->dev_addr,
+ NOTIFY_XHCI_RESET);
+
+   /*
+* The pci device address is expected like this:
+*
+*   PCI_BUS << 20 | PCI_SLOT << 15 | PCI_FUNC << 12
+*
+* But since RPi4's PCIe setup is hardwired, we know the address in
+* advance.
+*/
+   msg_notify_vl805_reset->dev_addr.body.req.dev_addr = 0x10;
+
+   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN,
+_notify_vl805_reset->hdr);
+   if (ret) {
+   printf("bcm2711: Faild to load vl805's firmware, %d\n", ret);
+   return -EIO;
+   }
+
+   udelay(200);
+
+   return 0;
+}
+
-- 
2.27.0



RE: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals available in prci

2020-06-29 Thread Sagar Kadam
Hello Jagan,
> -Original Message-
> From: Jagan Teki 
> Sent: Monday, June 29, 2020 9:00 PM
> To: Sagar Kadam 
> Cc: U-Boot-Denx ; Rick Chen ;
> Paul Walmsley ( Sifive) ; Palmer Dabbelt
> ; Anup Patel ; Atish Patra
> ; Lukasz Majewski ; Pragnesh
> Patel ; bin.m...@windriver.com; Simon Glass
> ; Trevor Woerner ; Eugeniy
> Paltsev ; Patrick Wildt
> ; Weijie Gao ; Fabio
> Estevam 
> Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals
> available in prci
> 
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
> 
> On Fri, Jun 26, 2020 at 8:51 AM Sagar Kadam 
> wrote:
> >
> > Hi Jagan,
> >
> > > -Original Message-
> > > From: Jagan Teki 
> > > Sent: Thursday, June 25, 2020 11:13 PM
> > > To: Sagar Kadam 
> > > Cc: U-Boot-Denx ; Rick Chen
> ;
> > > Paul Walmsley ( Sifive) ; Palmer Dabbelt
> > > ; Anup Patel ; Atish
> Patra
> > > ; Lukasz Majewski ; Pragnesh
> > > Patel ; bin.m...@windriver.com; Simon
> Glass
> > > ; Trevor Woerner ; Eugeniy
> > > Paltsev ; Patrick Wildt
> > > ; Weijie Gao ; Fabio
> > > Estevam 
> > > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset
> signals
> > > available in prci
> > >
> > > [External Email] Do not click links or attachments unless you recognize
> the
> > > sender and know the content is safe
> > >
> > > On Thu, Jun 25, 2020 at 5:56 PM Sagar Shrikant Kadam
> > >  wrote:
> > > >
> > > > Add bit indexes for reset signals within the PRCI module
> > > > on FU540-C000 SoC.
> > > > The DDR and ethernet sub-system's have reset signals
> > > > indicated by these reset indexes.
> > > >
> > > > Signed-off-by: Sagar Shrikant Kadam 
> > > > Reviewed-by: Pragnesh Patel 
> > > > Reviewed-by: Bin Meng 
> > > > ---
> > > >  include/dt-bindings/clock/sifive-fu540-prci.h | 8 
> > > >  1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/include/dt-bindings/clock/sifive-fu540-prci.h b/include/dt-
> > > bindings/clock/sifive-fu540-prci.h
> > > > index 6a0b70a..1c03b09 100644
> > > > --- a/include/dt-bindings/clock/sifive-fu540-prci.h
> > > > +++ b/include/dt-bindings/clock/sifive-fu540-prci.h
> > > > @@ -15,4 +15,12 @@
> > > >  #define PRCI_CLK_GEMGXLPLL2
> > > >  #define PRCI_CLK_TLCLK3
> > > >
> > > > +/* Reset bit indexes to be used by driver */
> > > > +#define PRCI_RST_DDR_CTRL_N0
> > > > +#define PRCI_RST_DDR_AXI_N 1
> > > > +#define PRCI_RST_DDR_AHB_N 2
> > > > +#define PRCI_RST_DDR_PHY_N 3
> > > > +/* bit 4 is reserved bit */
> > > > +#define PRCI_RST_RSVD_N4
> > > > +#define PRCI_RST_GEMGXL_N  5
> > > >  #endif
> > >
> > > Do these bindings are synced from Linux? If Yes better to sync with a
> > > particular commit or tag rather than patch.
> > >
> >
> > No, these reset bindings are not synced from Linux.
> 
> This is synced file from Linux, better to inline with Linux files
> always, if these bindings are not related to Linux then maintain it in
> a separate file or support it in Linux first if they do require for
> Linux.
> 
Ohh. Sorry I thought you were asking if reset-bindings are from Linux.
Yes this file is synced from Linux but these reset-bindings are not related
to Linux. So I can split it and place reset bindings into another file:
"include/dt-bindings/reset/sifive-fu540-reset.h"
and include it wherever required.  Please let me know if this sounds okay.

Thanks & BR,
Sagar Kadam

> Jagan.


Re: [PATCH] gitlab: add pycrypto for arm64

2020-06-29 Thread Tom Rini
On Sun, Jun 28, 2020 at 06:20:52PM +0800, Kever Yang wrote:

> pycrypto is needed for script to generate correct its.
> 
> Signed-off-by: Kever Yang 
> ---
> 
>  .gitlab-ci.yml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index f2e491c117..4841e7afbe 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -67,7 +67,7 @@ build all 64bit ARM platforms:
>script:
>  - virtualenv -p /usr/bin/python3 /tmp/venv
>  - . /tmp/venv/bin/activate
> -- pip install pyelftools
> +- pip install pyelftools pycrypto
>  - ret=0;
>./tools/buildman/buildman -o /tmp -P -E -W aarch64 || ret=$?;
>if [[ $ret -ne 0 ]]; then
> @@ -159,7 +159,7 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
>export USER=gitlab;
>virtualenv -p /usr/bin/python3 /tmp/venv;
>. /tmp/venv/bin/activate;
> -  pip install pyelftools pytest;
> +  pip install pyelftools pytest pycrypto;
>export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl;
>export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
>export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";

We need to update all of the CI config files to install the needed
modules.  I also assume we haven't pushed changes in yet that require
pycrypto, so which tool is going to need it?  I want to make sure we
document it and perhaps we need to start thinking about a
requirement.txt for our python tools if it's binman that needs it (as
that's what also needs pyelftools).  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] video: rockchip: fix HDMI 4K resolution

2020-06-29 Thread Anatolij Gustschin
On Mon, 29 Jun 2020 16:53:44 +0200
Anatolij Gustschin ag...@denx.de wrote:

> 3480 is not valid XRES, use 3840 as default.
> 
> Fixes: 05c65a82c3c1 ("video: rockchip: Support 4K resolution for rk3399, 
> HDMI")
> Signed-off-by: Anatolij Gustschin 
> Cc: Jagan Teki 
> ---
>  drivers/video/rockchip/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-video/master.

--
Anatolij


Re: [PATCH] cmd: add clone command

2020-06-29 Thread Tom Rini
On Sat, Jun 27, 2020 at 11:15:49AM +0800, John Chau wrote:

> From: John Chau 
> 
> This patch adds a feature for block device cloning similar to dd
> command, this should be useful for boot-strapping a device where
> usb gadget or networking is not available. For instance one can
> clone a factory image into a blank emmc from an external sd card.
> 
> Signed-off-by: John Chau 

In general, checkpatch.pl complains a lot and those need to be fixed.

[snip]
> +config CMD_CLONE
> + bool "clone"
> + depends on BLK
> + select CLONE

There's no "config CLONE" so we don't need this line.

[snip]
> +//FIXME: we assume blk size of both devices can be divided by 1M, which 
> should be normal
> +#define BUFSIZE (1 * 1024 * 1024)

Can we do some run-time checks of the block sizes of each device and
confirm this assumption and fail if it's not true?

Finally, we should also enable this on sandbox so that it's build-tested
and put through coverity.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals available in prci

2020-06-29 Thread Jagan Teki
On Fri, Jun 26, 2020 at 8:51 AM Sagar Kadam  wrote:
>
> Hi Jagan,
>
> > -Original Message-
> > From: Jagan Teki 
> > Sent: Thursday, June 25, 2020 11:13 PM
> > To: Sagar Kadam 
> > Cc: U-Boot-Denx ; Rick Chen ;
> > Paul Walmsley ( Sifive) ; Palmer Dabbelt
> > ; Anup Patel ; Atish Patra
> > ; Lukasz Majewski ; Pragnesh
> > Patel ; bin.m...@windriver.com; Simon Glass
> > ; Trevor Woerner ; Eugeniy
> > Paltsev ; Patrick Wildt
> > ; Weijie Gao ; Fabio
> > Estevam 
> > Subject: Re: [PATCH v2 1/5] dt-bindings: prci: add indexes for reset signals
> > available in prci
> >
> > [External Email] Do not click links or attachments unless you recognize the
> > sender and know the content is safe
> >
> > On Thu, Jun 25, 2020 at 5:56 PM Sagar Shrikant Kadam
> >  wrote:
> > >
> > > Add bit indexes for reset signals within the PRCI module
> > > on FU540-C000 SoC.
> > > The DDR and ethernet sub-system's have reset signals
> > > indicated by these reset indexes.
> > >
> > > Signed-off-by: Sagar Shrikant Kadam 
> > > Reviewed-by: Pragnesh Patel 
> > > Reviewed-by: Bin Meng 
> > > ---
> > >  include/dt-bindings/clock/sifive-fu540-prci.h | 8 
> > >  1 file changed, 8 insertions(+)
> > >
> > > diff --git a/include/dt-bindings/clock/sifive-fu540-prci.h b/include/dt-
> > bindings/clock/sifive-fu540-prci.h
> > > index 6a0b70a..1c03b09 100644
> > > --- a/include/dt-bindings/clock/sifive-fu540-prci.h
> > > +++ b/include/dt-bindings/clock/sifive-fu540-prci.h
> > > @@ -15,4 +15,12 @@
> > >  #define PRCI_CLK_GEMGXLPLL2
> > >  #define PRCI_CLK_TLCLK3
> > >
> > > +/* Reset bit indexes to be used by driver */
> > > +#define PRCI_RST_DDR_CTRL_N0
> > > +#define PRCI_RST_DDR_AXI_N 1
> > > +#define PRCI_RST_DDR_AHB_N 2
> > > +#define PRCI_RST_DDR_PHY_N 3
> > > +/* bit 4 is reserved bit */
> > > +#define PRCI_RST_RSVD_N4
> > > +#define PRCI_RST_GEMGXL_N  5
> > >  #endif
> >
> > Do these bindings are synced from Linux? If Yes better to sync with a
> > particular commit or tag rather than patch.
> >
>
> No, these reset bindings are not synced from Linux.

This is synced file from Linux, better to inline with Linux files
always, if these bindings are not related to Linux then maintain it in
a separate file or support it in Linux first if they do require for
Linux.

Jagan.


Re: [PATCH] sunxi: Add support for using UART4 as console on A64

2020-06-29 Thread Maxime Ripard
Hi,

On Mon, Jun 29, 2020 at 12:09:38PM +0300, Nazım Gediz Aydındoğmuş wrote:
> A64 has UART4 but it was in conflict with R_UART of older SoCs (e.g. A23).
> 
> This commit adds necessary definitions and checks to use UART4 port on A64.
> 
> Signed-off-by: Nazım Gediz Aydındoğmuş 
> ---
> 
>  arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
>  arch/arm/mach-sunxi/board.c| 4 
>  arch/arm/mach-sunxi/clock_sun6i.c  | 3 ++-
>  include/configs/sunxi-common.h | 6 ++
>  4 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index a646ea6a3c..1407aff25f 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -176,6 +176,7 @@ enum sunxi_gpio_number {
>  #define SUNXI_GPD_LCD0   2
>  #define SUNXI_GPD_LVDS0  3
>  #define SUNXI_GPD_PWM2
> +#define SUN50I_GPD_UART4 3
>  
>  #define SUN5I_GPE_SDC2   3
>  #define SUN8I_GPE_TWI2   3
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index f40fccd8f8..7d95b7dd29 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -140,6 +140,10 @@ static int gpio_init(void)
>   sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL_R_UART);
>   sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL_R_UART);
>   sunxi_gpio_set_pull(SUNXI_GPL(3), SUNXI_GPIO_PULL_UP);
> +#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I)
> + sunxi_gpio_set_cfgpin(SUNXI_GPD(2), SUN50I_GPD_UART4);
> + sunxi_gpio_set_cfgpin(SUNXI_GPD(3), SUN50I_GPD_UART4);
> + sunxi_gpio_set_pull(SUNXI_GPD(3), SUNXI_GPIO_PULL_UP);
>  #else
>  #error Unsupported console port number. Please fix pin mux settings in 
> board.c
>  #endif
> diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
> b/arch/arm/mach-sunxi/clock_sun6i.c
> index 8e84062bd7..4bb2d66b1e 100644
> --- a/arch/arm/mach-sunxi/clock_sun6i.c
> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
> @@ -83,7 +83,8 @@ void clock_init_sec(void)
>  
>  void clock_init_uart(void)
>  {
> -#if CONFIG_CONS_INDEX < 5
> +#if CONFIG_CONS_INDEX < 5 || \
> +  defined(CONFIG_MACH_SUN50I) && CONFIG_CONS_INDEX < 6
>   struct sunxi_ccm_reg *const ccm =
>   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
>  
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 5b0bec0561..f7a97b3dec 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -45,8 +45,12 @@
>  # define CONFIG_SYS_NS16550_COM2 SUNXI_UART1_BASE
>  # define CONFIG_SYS_NS16550_COM3 SUNXI_UART2_BASE
>  # define CONFIG_SYS_NS16550_COM4 SUNXI_UART3_BASE
> +#if defined(CONFIG_MACH_SUN50I)
> +# define CONFIG_SYS_NS16550_COM5 SUNXI_UART4_BASE
> +#else
>  # define CONFIG_SYS_NS16550_COM5 SUNXI_R_UART_BASE
>  #endif
> +#endif
>  
>  /* CPU */
>  #define COUNTER_FREQUENCY2400
> @@ -248,6 +252,8 @@ extern int soft_i2c_gpio_scl;
>  #define OF_STDOUT_PATH   "/soc@01c0/serial@01c28800:115200"
>  #elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I)
>  #define OF_STDOUT_PATH   "/soc@01c0/serial@01f02800:115200"
> +#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I)
> +#define OF_STDOUT_PATH   "/soc@01c0/serial@01c29000:115200"

The soc node doesn't have a unit-address on the A64
Maxime


signature.asc
Description: PGP signature


Re: [PATCH] video: rockchip: fix HDMI 4K resolution

2020-06-29 Thread Jagan Teki
On Mon, Jun 29, 2020 at 8:23 PM Anatolij Gustschin  wrote:
>
> 3480 is not valid XRES, use 3840 as default.
>
> Fixes: 05c65a82c3c1 ("video: rockchip: Support 4K resolution for rk3399, 
> HDMI")
> Signed-off-by: Anatolij Gustschin 
> Cc: Jagan Teki 
> ---
>  drivers/video/rockchip/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/rockchip/Kconfig b/drivers/video/rockchip/Kconfig
> index cfd774ead6..5215a71f99 100644
> --- a/drivers/video/rockchip/Kconfig
> +++ b/drivers/video/rockchip/Kconfig
> @@ -22,7 +22,7 @@ menuconfig VIDEO_ROCKCHIP
>  config VIDEO_ROCKCHIP_MAX_XRES
>  int "Maximum horizontal resolution (for memory allocation purposes)"
> depends on VIDEO_ROCKCHIP
> -   default 3480 if ROCKCHIP_RK3399 && DISPLAY_ROCKCHIP_HDMI
> +   default 3840 if ROCKCHIP_RK3399 && DISPLAY_ROCKCHIP_HDMI

Thanks for the patch I was miss reading 3480 as 3840 before.

Reviewed-by: Jagan Teki 
Tested-by: Jagan Teki  # roc-rk3399-pc


[PATCH] video: rockchip: fix HDMI 4K resolution

2020-06-29 Thread Anatolij Gustschin
3480 is not valid XRES, use 3840 as default.

Fixes: 05c65a82c3c1 ("video: rockchip: Support 4K resolution for rk3399, HDMI")
Signed-off-by: Anatolij Gustschin 
Cc: Jagan Teki 
---
 drivers/video/rockchip/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/rockchip/Kconfig b/drivers/video/rockchip/Kconfig
index cfd774ead6..5215a71f99 100644
--- a/drivers/video/rockchip/Kconfig
+++ b/drivers/video/rockchip/Kconfig
@@ -22,7 +22,7 @@ menuconfig VIDEO_ROCKCHIP
 config VIDEO_ROCKCHIP_MAX_XRES
 int "Maximum horizontal resolution (for memory allocation purposes)"
depends on VIDEO_ROCKCHIP
-   default 3480 if ROCKCHIP_RK3399 && DISPLAY_ROCKCHIP_HDMI
+   default 3840 if ROCKCHIP_RK3399 && DISPLAY_ROCKCHIP_HDMI
default 1920
help
  The maximum horizontal resolution to support for the framebuffer.
-- 
2.17.1



Re: [PATCH 03/16] dh_imx6: Switch to full DM-aware

2020-06-29 Thread Tom Rini
On Mon, Jun 29, 2020 at 12:27:08PM +, Ludwig Zenz wrote:
> On 25/06/20 2:52 PM, Tom Rini wrote:
> > On Thu, Jun 25, 2020 at 02:52:58PM +, Ludwig Zenz wrote:
> >> On 22/06/20 9:38 AM, Tom Rini wrote:
> >> > On Mon, Jun 22, 2020 at 09:38:36AM +, Ludwig Zenz wrote:
> >> >
> >> >> On 6/13/20 3:55 PM, Jagan Teki wrote:
> >> >> > Enable DM_SPI/DM_SPI_FLASH with a related config option.
> >> >> > 
> >> >> > Build fine, but not tested.
> >> >> 
> >> >> Hello,
> >> >> 
> >> >> due to memory limitations in the SRAM of the i.MX6S in SPL we have not 
> >> >> used the device tree. Have the restrictions been removed in the 
> >> >> meantime? We need a single binary for the i.MX6 q/d/dl/s variants of 
> >> >> our system on module.
> >> >> 
> >> >> I think this patch breaks the board support for our module.
> >> >
> >> > I _think_ i.MX is making use of the generic hooks to cause build time 
> >> > failures when we grow too large.  And we have addressed some, but not 
> >> > all of the concerns about DM size.  Can you please test this patch?  If 
> >> > it doesn't work doing:
> >> >
> >> >> > diff --git a/include/configs/dh_imx6.h 
> >> >> > b/include/configs/dh_imx6.h index 5bfdf4044b..5fb84f72a2 100644
> >> >> > --- a/include/configs/dh_imx6.h
> >> >> > +++ b/include/configs/dh_imx6.h
> >> >> > @@ -53,12 +53,6 @@
> >> >> >  /* SATA Configs */
> >> >> >  #define CONFIG_LBA48
> >> >> >  
> >> >> > -/* SPI Flash Configs */
> >> >> > -#if defined(CONFIG_SPL_BUILD)
> >> >> > -#undef CONFIG_DM_SPI
> >> >> > -#undef CONFIG_DM_SPI_FLASH
> >> >> > -#endif
> >> >
> >> > is still needed as we have a symbol to control DM SPI in SPL directly so 
> >> > the above isn't doing what you imply you want.  Thanks!
> >> >
> 
> I can remove the above defines from include/configs/dh_imx6.h when I add the 
> following patch:
> 
> include/config_uncmd_spl.h
> @@ -14,6 +14,7 @@
>  #undef CONFIG_DM_SERIAL
>  #undef CONFIG_DM_I2C
>  #undef CONFIG_DM_SPI
> +#undef CONFIG_DM_SPI_FLASH
>  #endif
> 
> >>
> >> 
> >> With the above patch the board hangs after printing "U-Boot SPL 
> >> 2020.07-rc5-38776-g922c6d5d009-dirty (Jun 25 2020 - 16:34:23 +0200)".
> >> 
> >> Through some debugging i found the board hangs on calling gpio_request() 
> >> in dhcom_get_ddr3_code().
> >>  
> >> Just for testing I skipped dhcom_get_ddr3_code and hardcoded the DDR3 
> >> size. Then I get:
> >> 
> >> Missing DTB
> >> fdtdec_setup() returned error -1
> >> ### ERROR ### Please RESET the board ###
> >> 
> >> Unfortunately I have not found out how the SPL should load the devicetree. 
> >> Can you give me a hint for this?
> >
> >Ah, so you've not done any SPL DM migration.
> >
> >So there's two paths here.  Path 1, the config header snippet that got 
> >things rolling here does need to be removed as "no DM SPI in SPL" means 
> >CONFIG_SPL_DM_SPI=n and not "CONFIG_DM_SPI=n if CONFIG_SPL_BUILD".  We are 
> >not now, and are not at the point where we can say we will be at some future 
> >point, saying everyone must use DM in SPL.  You may want to examine the 
> >.config you get today from running dh_imx6_defconfig and seeing what 
> >can/should be disabled, if anything, that's an unexpected enabled option.  
> >Path 2, look at something like mx6cuboxi and convert to CONFIG_SPL_DM=y
> >
> 
> The CONFIG_SPL_DM_SPI is not in the .config of my build. The little patch for 
> include/config_uncmd_spl.h from above allows me to clean up dh_imx6.h.
> 
> Remark on path 2: mx6cuboxi avoids gpio usage in spl for some reason. We need 
> gpio support to detect the DDR3 size. I would like to go with path 1.
> 
> How can I check if adding CONFIG_DM_SPI_FLASH to include/config_uncmd_spl.h 
> causes problems for other boards?

So this is another example then where we do need
http://patchwork.ozlabs.org/project/uboot/patch/20200604151153.3980-4-zhiqiang@nxp.com/
and I'll be pushing that to -next shortly, as it needed
http://patchwork.ozlabs.org/project/uboot/patch/20200627120041.11223-1-tr...@konsulko.com/
as well.  Thanks for digging in to this more.

-- 
Tom


signature.asc
Description: PGP signature


Re: [EXT] [PATCH 1/1] power: pmic_pca9450: fix PCA9450A I2C address

2020-06-29 Thread Ye Li
On Mon, 2020-06-29 at 12:11 +0200, Sébastien Szymanski wrote:
> Caution: EXT Email
> 
> On 6/29/20 11:51 AM, Ye Li wrote:
> > 
> > On Mon, 2020-06-29 at 10:42 +0200, Sébastien Szymanski wrote:
> > > 
> > > Caution: EXT Email
> > > 
> > > PCA9450A I2C address is 0x25. Fix it.
> > > 
> > > Signed-off-by: Sébastien Szymanski  > > com>
> > > ---
> > >  drivers/power/pmic/pmic_pca9450.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/power/pmic/pmic_pca9450.c
> > > b/drivers/power/pmic/pmic_pca9450.c
> > > index 67a9090200..c0fb78c4cd 100644
> > > --- a/drivers/power/pmic/pmic_pca9450.c
> > > +++ b/drivers/power/pmic/pmic_pca9450.c
> > > @@ -23,7 +23,7 @@ int power_pca9450a_init(unsigned char bus)
> > > p->name = pca9450_name;
> > > p->interface = PMIC_I2C;
> > > p->number_of_regs = PCA9450_REG_NUM;
> > > -   p->hw.i2c.addr = 0x35;
> > > +   p->hw.i2c.addr = 0x25;
> > The address 0x35 is correct for PCA9540A. You are probably using
> > PCA9540B/C which address is 0x25. If so, please
> > call power_pca9450b_init.
> No.
> I am using a PCA9450A chip and its address is 0x25:
> 
> # i2cget -f -y 0 0x25 0x00
> 0x10
> 
> Moreover, the datasheet says it's 0x25. [1]
> 
> [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.nxp.com%2Fdocs%2Fen%2Fdata-
> sheet%2FPCA9450DS.pdfdata=02%7C01%7Cye.li%40nxp.com%7Cf58d2e0f30
> 7045ca2b7408d81c14d040%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6
> 37290222999360806sdata=cLYNDpYxwFaDrMSq%2B%2F2bivTXw9a8BAkUgTf3%
> 2B5mWcWg%3Dreserved=0
> 
> Regards,

Our doc shows the i2c address has a choice by MTP. 

The I2C address at Power-On Reset is as follows:
• Write address: 0x6A ( MTP Option : 4A )
• Read address: 0x6B ( MTP Option : 4B )


And we also has an 8MM board (not for customer) using PCA9450A with
0x35 address. 

Best regards,
Ye Li
> 
> > 
> > 
> > Best regards,
> > Ye Li
> > > 
> > > p->hw.i2c.tx_num = 1;
> > > p->bus = bus;
> > > 
> > > --
> > > 2.26.2
> 
> --
> Sébastien Szymanski, Armadeus Systems
> Software engineer

Re: [PATCH 03/16] dh_imx6: Switch to full DM-aware

2020-06-29 Thread Ludwig Zenz
On 25/06/20 2:52 PM, Tom Rini wrote:
> On Thu, Jun 25, 2020 at 02:52:58PM +, Ludwig Zenz wrote:
>> On 22/06/20 9:38 AM, Tom Rini wrote:
>> > On Mon, Jun 22, 2020 at 09:38:36AM +, Ludwig Zenz wrote:
>> >
>> >> On 6/13/20 3:55 PM, Jagan Teki wrote:
>> >> > Enable DM_SPI/DM_SPI_FLASH with a related config option.
>> >> > 
>> >> > Build fine, but not tested.
>> >> 
>> >> Hello,
>> >> 
>> >> due to memory limitations in the SRAM of the i.MX6S in SPL we have not 
>> >> used the device tree. Have the restrictions been removed in the meantime? 
>> >> We need a single binary for the i.MX6 q/d/dl/s variants of our system on 
>> >> module.
>> >> 
>> >> I think this patch breaks the board support for our module.
>> >
>> > I _think_ i.MX is making use of the generic hooks to cause build time 
>> > failures when we grow too large.  And we have addressed some, but not all 
>> > of the concerns about DM size.  Can you please test this patch?  If it 
>> > doesn't work doing:
>> >
>> >> > diff --git a/include/configs/dh_imx6.h 
>> >> > b/include/configs/dh_imx6.h index 5bfdf4044b..5fb84f72a2 100644
>> >> > --- a/include/configs/dh_imx6.h
>> >> > +++ b/include/configs/dh_imx6.h
>> >> > @@ -53,12 +53,6 @@
>> >> >  /* SATA Configs */
>> >> >  #define CONFIG_LBA48
>> >> >  
>> >> > -/* SPI Flash Configs */
>> >> > -#if defined(CONFIG_SPL_BUILD)
>> >> > -#undef CONFIG_DM_SPI
>> >> > -#undef CONFIG_DM_SPI_FLASH
>> >> > -#endif
>> >
>> > is still needed as we have a symbol to control DM SPI in SPL directly so 
>> > the above isn't doing what you imply you want.  Thanks!
>> >

I can remove the above defines from include/configs/dh_imx6.h when I add the 
following patch:

include/config_uncmd_spl.h
@@ -14,6 +14,7 @@
 #undef CONFIG_DM_SERIAL
 #undef CONFIG_DM_I2C
 #undef CONFIG_DM_SPI
+#undef CONFIG_DM_SPI_FLASH
 #endif

>>
>> 
>> With the above patch the board hangs after printing "U-Boot SPL 
>> 2020.07-rc5-38776-g922c6d5d009-dirty (Jun 25 2020 - 16:34:23 +0200)".
>> 
>> Through some debugging i found the board hangs on calling gpio_request() in 
>> dhcom_get_ddr3_code().
>>  
>> Just for testing I skipped dhcom_get_ddr3_code and hardcoded the DDR3 size. 
>> Then I get:
>> 
>> Missing DTB
>> fdtdec_setup() returned error -1
>> ### ERROR ### Please RESET the board ###
>> 
>> Unfortunately I have not found out how the SPL should load the devicetree. 
>> Can you give me a hint for this?
>
>Ah, so you've not done any SPL DM migration.
>
>So there's two paths here.  Path 1, the config header snippet that got things 
>rolling here does need to be removed as "no DM SPI in SPL" means 
>CONFIG_SPL_DM_SPI=n and not "CONFIG_DM_SPI=n if CONFIG_SPL_BUILD".  We are not 
>now, and are not at the point where we can say we will be at some future 
>point, saying everyone must use DM in SPL.  You may want to examine the 
>.config you get today from running dh_imx6_defconfig and seeing what 
>can/should be disabled, if anything, that's an unexpected enabled option.  
>Path 2, look at something like mx6cuboxi and convert to CONFIG_SPL_DM=y
>

The CONFIG_SPL_DM_SPI is not in the .config of my build. The little patch for 
include/config_uncmd_spl.h from above allows me to clean up dh_imx6.h.

Remark on path 2: mx6cuboxi avoids gpio usage in spl for some reason. We need 
gpio support to detect the DDR3 size. I would like to go with path 1.

How can I check if adding CONFIG_DM_SPI_FLASH to include/config_uncmd_spl.h 
causes problems for other boards?

regards,
Ludwig


Re: [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware

2020-06-29 Thread Tom Rini
On Mon, Jun 29, 2020 at 07:56:53AM +0530, Lokesh Vutla wrote:
> +Tom
> 
> On 23/06/20 8:11 pm, Jan Kiszka wrote:
> > On 23.06.20 14:37, Jan Kiszka wrote:
> >> On 23.06.20 13:50, Lokesh Vutla wrote:
> >>>
> >>>
> >>> On 23/06/20 4:45 pm, Jan Kiszka wrote:
>  From: Jan Kiszka 
> 
>  To avoid the need of extra boot scripting on AM65x for loading a
>  watchdog firmware, add the required rproc init and loading logic for the
>  first R5F core to the watchdog start handler. The firmware itself is
>  embedded into U-Boot binary.
> 
>  One possible firmware source is https://github.com/siemens/k3-rti-wdt.
> 
>  Signed-off-by: Jan Kiszka 
>  ---
>    drivers/watchdog/Kconfig  | 20 
>    drivers/watchdog/Makefile |  3 +++
>    drivers/watchdog/rti_wdt.c    | 24 
>    drivers/watchdog/rti_wdt_fw.S | 20 
>    4 files changed, 67 insertions(+)
>    create mode 100644 drivers/watchdog/rti_wdt_fw.S
> 
>  diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>  index ee99bd2af1..fd6ab9a85b 100644
>  --- a/drivers/watchdog/Kconfig
>  +++ b/drivers/watchdog/Kconfig
>  @@ -162,6 +162,26 @@ config WDT_K3_RTI
>      Say Y here if you want to include support for the K3 watchdog
>      timer (RTI module) available in the K3 generation of processors.
>  +if WDT_K3_RTI
>  +
>  +config WDT_K3_RTI_LOAD_FW
>  +    bool "Load watchdog firmware"
>  +    depends on REMOTEPROC
>  +    help
>  +  Automatically load the specified firmware image into the MCU R5F
>  +  core 0. On the AM65x, this firmware is supposed to handle the 
>  expiry
>  +  of the watchdog timer, typically by resetting the system.
>  +
>  +config WDT_K3_RTI_FW_FILE
>  +    string "Watchdog firmware image file"
>  +    default "k3-rti-wdt.fw"
>  +    depends on WDT_K3_RTI_LOAD_FW
>  +    help
>  +  Firmware image to be embedded into U-Boot and loaded on watchdog
>  +  start.
>  +
>  +endif
>  +
>    config WDT_SANDBOX
>    bool "Enable Watchdog Timer support for Sandbox"
>    depends on SANDBOX && WDT
>  diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
>  index 16bdbf4970..bf58684875 100644
>  --- a/drivers/watchdog/Makefile
>  +++ b/drivers/watchdog/Makefile
>  @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
>    obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
>    obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
>    obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
>  +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o
>    obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
>    obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
>    obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
>    obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
>  +
>  +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) 
>  FORCE
>  diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
>  index ebe29c7409..38e82a6b6b 100644
>  --- a/drivers/watchdog/rti_wdt.c
>  +++ b/drivers/watchdog/rti_wdt.c
>  @@ -14,6 +14,7 @@
>    #include 
>    #include 
>    #include 
>  +#include 
>    /* Timer register set definition */
>    #define RTIDWDCTRL    0x90
>  @@ -37,11 +38,16 @@
>    #define WDT_PRELOAD_MAX    0xfff
>  +#define RTI_PROC_ID    0
> >>>
> >>> Can we get the rproc id from DT?
> >>
> >> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable.
> >>
> > 
> > I'm now probing for the first instance of "ti,am654-r5f" compatible. That
> > excludes usage for the J721E for now, but that one is fine without firmware 
> > -
> > provided there is way to prevent power-down for RTI watchdog otherwise...
> 
> I was more of thinking to have a DT property to reference R5-core. But 
> anyways,
> the property is not present in kernel. I am okay with this for now.

Note that not all properties in a DT in Linux need to be used in Linux,
this is something I _think_ there is growing understanding of.

>  +
>    struct rti_wdt_priv {
>    phys_addr_t regs;
>    unsigned int clk_khz;
>    };
>  +extern const u32 rti_wdt_fw[];
>  +extern const int rti_wdt_fw_size;
> >>>
> >>> FIT is the preferred way of packing images in U-Boot. Can you try using 
> >>> it?
> >>
> >> How does that work? Some example for me?
> >>
> > 
> > If you happen to refer to fs-loader: That does not target OSPI, our primary 
> > use
> > case.
> 
> No. I was thinking to pack the image in FIT along with ATF and OPTEE like in
> k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the
> firmware.
> 
> > 
> >> What benefit would that bring? There are other users of this pattern, e.g.
> >> board/xilinx/zynqmp/pm_cfg_obj.S.
> 
> I didn't know U-Boot is accepting this. 

Re: [PATCH 2/2] arm: mvebu: a38x: Adjust UTMI PHY parameters

2020-06-29 Thread Stefan Roese

On 25.06.20 02:48, Chris Packham wrote:

When running USB compliance tests on our Armada-385 hardware platforms
we have seen some eye mask violations. Marvell's internal documentation
says: Based on silicon test results, it is recommended to change the
impedance calibration threshold setting to 0x6 prior to calibration.

Port changes from Marvell's u-boot fork[1] to address this.

[1] - 
https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/a6221551

Signed-off-by: Chris Packham 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---

  .../serdes/a38x/high_speed_env_spec.c | 25 ---
  1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c 
b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index d4480622c89c..2454730e6d86 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -672,12 +672,29 @@ struct op_params usb2_power_up_params[] = {
{0xc200c, 0x0 /*NA*/, 0x100, {0x100}, 0, 0},
/* Phy0 register 3  - TX Channel control 0 */
{0xc400c, 0x0 /*NA*/, 0x100, {0x100}, 0, 0},
-   /* check PLLCAL_DONE is set and IMPCAL_DONE is set */
+   /* Decrease the amplitude of the low speed eye to meet the spec */
+   {0xc000c, 0x0 /*NA*/, 0xf000, {0x1000}, 0, 0},
+   {0xc200c, 0x0 /*NA*/, 0xf000, {0x1000}, 0, 0},
+   {0xc400c, 0x0 /*NA*/, 0xf000, {0x1000}, 0, 0},
+   /* Change the High speed impedance threshold */
+   {0xc0008, 0x0 /*NA*/, 0x700, {0x600}, 0, 0},
+   {0xc2008, 0x0 /*NA*/, 0x700, {0x600}, 0, 0},
+   {0xc4008, 0x0 /*NA*/, 0x700, {0x600}, 0, 0},
+   /* Change the squelch level of the receiver to meet the receiver 
electrical measurements (squelch and receiver sensitivity tests) */
+   {0xc0014, 0x0 /*NA*/, 0xf, {0x8}, 0, 0},
+   {0xc2014, 0x0 /*NA*/, 0xf, {0x8}, 0, 0},
+   {0xc4014, 0x0 /*NA*/, 0xf, {0x8}, 0, 0},
+   /* Check PLLCAL_DONE is set and IMPCAL_DONE is set */
{0xc0008, 0x0 /*NA*/, 0x8080, {0x8080}, 1, 1000},
-   /* check REG_SQCAL_DONE  is set */
+   /* Check REG_SQCAL_DONE  is set */
{0xc0018, 0x0 /*NA*/, 0x8000, {0x8000}, 1, 1000},
-   /* check PLL_READY  is set */
-   {0xc, 0x0 /*NA*/, 0x8000, {0x8000}, 1, 1000}
+   /* Check PLL_READY  is set */
+   {0xc, 0x0 /*NA*/, 0x8000, {0x8000}, 1, 1000},
+   /* Start calibrate of high seed impedance */
+   {0xc0008, 0x0 /*NA*/, 0x2000, {0x2000}, 0, 0},
+   {0x0, 0x0 /*NA*/, 0x0, {0x0}, 10, 0},
+   /* De-assert  the calibration signal */
+   {0xc0008, 0x0 /*NA*/, 0x2000, {0x0}, 0, 0},
  };
  
  /*





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 1/2] arm: mvebu: a38x: Fix typo

2020-06-29 Thread Stefan Roese

On 25.06.20 02:48, Chris Packham wrote:

Fix spelling of Alignment.

Signed-off-by: Chris Packham 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---

  arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c 
b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
index 67a00cf1cf7b..d4480622c89c 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/high_speed_env_spec.c
@@ -533,7 +533,7 @@ struct op_params pex_and_usb3_tx_config_params3[] = {
  struct op_params pex_by4_config_params[] = {
/* unit_base_reg, unit_offset, mask, data, wait_time, num_of_loops */
{GLOBAL_CLK_SRC_HI, 0x800, 0x7, {0x5, 0x0, 0x0, 0x2}, 0, 0},
-   /* Lane Alignement enable */
+   /* Lane Alignment enable */
{LANE_ALIGN_REG0, 0x800, 0x1000, {0x0, 0x0, 0x0, 0x0}, 0, 0},
/* Max PLL phy config */
{CALIBRATION_CTRL_REG, 0x800, 0x1000, {0x1000, 0x1000, 0x1000, 0x1000},



Re: U-Boot Logo showing incorrect colors with eLCDIF

2020-06-29 Thread Fabio Estevam
Hi Anatolij,

On Mon, Jun 29, 2020 at 4:31 AM Anatolij Gustschin  wrote:

> I've tested on mx6ul-14x14-evk, with current U-Boot master I do not
> see this problem any more.

Excellent! I saw Ye Li's patches that fixed the problem.

Thanks


[PATCH 1/1] riscv: Fix linking error when building u-boot-spl with no SMP support

2020-06-29 Thread Leo Yu-Chi Liang
Switch off SMP support when building u-boot-spl would cause linking error as 
follow:
undefined reference to 'secondary hart relocate' and 'smp_call_function'.
Add macro to wrap up proper code region that needs SMP configuration on.

Signed-off by: Leo Liang 
Cc: r...@andestech.com
---
 arch/riscv/cpu/start.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 5f1c220..e3222b1 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -191,6 +191,7 @@ spl_stack_gd_setup:
mv  sp, s0
 #endif
 
+#if CONFIG_IS_ENABLED(SMP)
/* set new stack and global data pointer on secondary harts */
 spl_secondary_hart_stack_gd_setup:
la  a0, secondary_hart_relocate
@@ -205,6 +206,7 @@ spl_secondary_hart_stack_gd_setup:
la  a0, secondary_harts_relocation_error
jal printf
jal hang
+#endif
 
/* set new global data pointer on main hart */
 1: mv  gp, s0
-- 
2.7.4



[PATCH] sunxi: Add support for using UART4 as console on A64

2020-06-29 Thread Nazım Gediz Aydındoğmuş
A64 has UART4 but it was in conflict with R_UART of older SoCs (e.g. A23).

This commit adds necessary definitions and checks to use UART4 port on A64.

Signed-off-by: Nazım Gediz Aydındoğmuş 
---

 arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
 arch/arm/mach-sunxi/board.c| 4 
 arch/arm/mach-sunxi/clock_sun6i.c  | 3 ++-
 include/configs/sunxi-common.h | 6 ++
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h 
b/arch/arm/include/asm/arch-sunxi/gpio.h
index a646ea6a3c..1407aff25f 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -176,6 +176,7 @@ enum sunxi_gpio_number {
 #define SUNXI_GPD_LCD0 2
 #define SUNXI_GPD_LVDS03
 #define SUNXI_GPD_PWM  2
+#define SUN50I_GPD_UART4   3
 
 #define SUN5I_GPE_SDC2 3
 #define SUN8I_GPE_TWI2 3
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index f40fccd8f8..7d95b7dd29 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -140,6 +140,10 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPL(2), SUN8I_GPL_R_UART);
sunxi_gpio_set_cfgpin(SUNXI_GPL(3), SUN8I_GPL_R_UART);
sunxi_gpio_set_pull(SUNXI_GPL(3), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPD(2), SUN50I_GPD_UART4);
+   sunxi_gpio_set_cfgpin(SUNXI_GPD(3), SUN50I_GPD_UART4);
+   sunxi_gpio_set_pull(SUNXI_GPD(3), SUNXI_GPIO_PULL_UP);
 #else
 #error Unsupported console port number. Please fix pin mux settings in board.c
 #endif
diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
b/arch/arm/mach-sunxi/clock_sun6i.c
index 8e84062bd7..4bb2d66b1e 100644
--- a/arch/arm/mach-sunxi/clock_sun6i.c
+++ b/arch/arm/mach-sunxi/clock_sun6i.c
@@ -83,7 +83,8 @@ void clock_init_sec(void)
 
 void clock_init_uart(void)
 {
-#if CONFIG_CONS_INDEX < 5
+#if CONFIG_CONS_INDEX < 5 || \
+  defined(CONFIG_MACH_SUN50I) && CONFIG_CONS_INDEX < 6
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 5b0bec0561..f7a97b3dec 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -45,8 +45,12 @@
 # define CONFIG_SYS_NS16550_COM2   SUNXI_UART1_BASE
 # define CONFIG_SYS_NS16550_COM3   SUNXI_UART2_BASE
 # define CONFIG_SYS_NS16550_COM4   SUNXI_UART3_BASE
+#if defined(CONFIG_MACH_SUN50I)
+# define CONFIG_SYS_NS16550_COM5   SUNXI_UART4_BASE
+#else
 # define CONFIG_SYS_NS16550_COM5   SUNXI_R_UART_BASE
 #endif
+#endif
 
 /* CPU */
 #define COUNTER_FREQUENCY  2400
@@ -248,6 +252,8 @@ extern int soft_i2c_gpio_scl;
 #define OF_STDOUT_PATH "/soc@01c0/serial@01c28800:115200"
 #elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN8I)
 #define OF_STDOUT_PATH "/soc@01c0/serial@01f02800:115200"
+#elif CONFIG_CONS_INDEX == 5 && defined(CONFIG_MACH_SUN50I)
+#define OF_STDOUT_PATH "/soc@01c0/serial@01c29000:115200"
 #else
 #error Unsupported console port nr. Please fix stdout-path in sunxi-common.h.
 #endif
-- 
2.17.1



[PATCH] fastboot: Support defining raw partitions without a partition table

2020-06-29 Thread Filip Brozovic
Add support for defining raw fastboot partitions in eMMC by specifying
the offset and size in an environment variable. Optionally, the eMMC
hardware partition number may also be specified.

This makes it possible to e.g. update only part of the eMMC boot
partition, instead of having to write the entire partition.

Signed-off-by: Filip Brozovic 
---
 doc/android/fastboot.rst  | 19 ++
 drivers/fastboot/fb_mmc.c | 75 ++-
 2 files changed, 85 insertions(+), 9 deletions(-)

diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
index de3f6c37d7..2877c3cbaa 100644
--- a/doc/android/fastboot.rst
+++ b/doc/android/fastboot.rst
@@ -85,6 +85,25 @@ for example::
 
 fastboot_partition_alias_boot=LNX
 
+Raw partition descriptors
+^
+
+In cases where no partition table is present, a raw partition descriptor can be
+defined, specifying the offset, size, and optionally the MMC hardware partition
+number for a given partition name.
+
+This is useful when using fastboot to flash files (e.g. SPL or U-Boot) to a
+specific offset in the eMMC boot partition, without having to update the entire
+boot partition.
+
+To define a raw partition descriptor, add an environment variable similar to::
+
+fastboot_raw_partition_=  [mmcpart ]
+
+for example::
+
+fastboot_raw_partition_boot=0x100 0x1f00 mmcpart 1
+
 Variable overrides
 ^^
 
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index b2f8932e1c..ae8e8e512f 100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -50,6 +50,48 @@ static int part_get_info_by_name_or_alias(struct blk_desc 
*dev_desc,
return ret;
 }
 
+static int raw_part_get_info_by_name(struct blk_desc *dev_desc,
+   const char *name, struct disk_partition *info, int *mmcpart)
+{
+   /* strlen("fastboot_raw_partition_") + PART_NAME_LEN + 1 */
+   char env_desc_name[23 + PART_NAME_LEN + 1];
+   char *raw_part_desc;
+   const char *argv[2];
+   const char **parg = argv;
+
+   /* check for raw partition descriptor */
+   strcpy(env_desc_name, "fastboot_raw_partition_");
+   strncat(env_desc_name, name, PART_NAME_LEN);
+   raw_part_desc = strdup(env_get(env_desc_name));
+   if (raw_part_desc == NULL)
+   return -ENODEV;
+
+   /*
+* parse partition descriptor
+*
+*   [mmcpart ]
+*/
+   for (; parg < argv + sizeof(argv) / sizeof(*argv); ++parg) {
+   *parg = strsep(_part_desc, " ");
+   if (*parg == NULL) {
+   pr_err("Invalid number of arguments.\n");
+   return -ENODEV;
+   }
+   }
+
+   info->start = simple_strtoul(argv[0], NULL, 0);
+   info->size = simple_strtoul(argv[1], NULL, 0);
+   info->blksz = dev_desc->blksz;
+   strncpy((char *)info->name, name, PART_NAME_LEN);
+
+   if (raw_part_desc) {
+   if (strcmp(strsep(_part_desc, " "), "mmcpart") == 0)
+   *mmcpart = simple_strtoul(raw_part_desc, NULL, 0);
+   }
+
+   return 0;
+}
+
 /**
  * fb_mmc_blk_write() - Write/erase MMC in chunks of FASTBOOT_MAX_BLK_WRITE
  *
@@ -376,7 +418,8 @@ int fastboot_mmc_get_part_info(const char *part_name,
   struct blk_desc **dev_desc,
   struct disk_partition *part_info, char *response)
 {
-   int r;
+   int r = 0;
+   int mmcpart;
 
*dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
if (!*dev_desc) {
@@ -388,10 +431,12 @@ int fastboot_mmc_get_part_info(const char *part_name,
return -ENOENT;
}
 
-   r = part_get_info_by_name_or_alias(*dev_desc, part_name, part_info);
-   if (r < 0) {
-   fastboot_fail("partition not found", response);
-   return r;
+   if (raw_part_get_info_by_name(*dev_desc, part_name, part_info, 
) < 0) {
+   r = part_get_info_by_name_or_alias(*dev_desc, part_name, 
part_info);
+   if (r < 0) {
+   fastboot_fail("partition not found", response);
+   return r;
+   }
}
 
return r;
@@ -410,6 +455,7 @@ void fastboot_mmc_flash_write(const char *cmd, void 
*download_buffer,
 {
struct blk_desc *dev_desc;
struct disk_partition info;
+   int mmcpart = 0;
 
dev_desc = blk_get_dev("mmc", CONFIG_FASTBOOT_FLASH_MMC_DEV);
if (!dev_desc || dev_desc->type == DEV_TYPE_UNKNOWN) {
@@ -482,7 +528,13 @@ void fastboot_mmc_flash_write(const char *cmd, void 
*download_buffer,
}
 #endif
 
-   if (part_get_info_by_name_or_alias(dev_desc, cmd, ) < 0) {
+   if (raw_part_get_info_by_name(dev_desc, cmd, , ) == 0) {
+   if (blk_dselect_hwpart(dev_desc, mmcpart)) {
+   pr_err("Failed to select hwpart\n");
+   

[PATCH 1/1] efi_loader: fix incorrect use of EFI_EXIT()

2020-06-29 Thread Heinrich Schuchardt
efi_get_variable_common() does not use EFI_ENTRY(). So we should not use
EFI_EXIT() either.

Fixes: 767f6eeb01d3 ("efi_loader: variable: support variable authentication")
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_variable.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6271dbcf41..c262cb5972 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -606,7 +606,7 @@ static efi_status_t efi_get_variable_common(u16 
*variable_name,
u32 attr;

if (!variable_name || !vendor || !data_size)
-   return EFI_EXIT(EFI_INVALID_PARAMETER);
+   return EFI_INVALID_PARAMETER;

ret = efi_to_native(_name, variable_name, vendor);
if (ret)
--
2.27.0



[PATCH 2/2] mtd: nand: raw: denali: Wait for reset completion status

2020-06-29 Thread Ley Foon Tan
Fixed delay 200us is not working in certain platforms. Change to
poll for reset completion status to have more reliable reset process.

Controller will set the rst_comp bit in intr_status register after
controller has completed its reset and initialization process.

Signed-off-by: Radu Bacrau 
Signed-off-by: Ley Foon Tan 
---
 drivers/mtd/nand/raw/denali.c| 11 +++
 drivers/mtd/nand/raw/denali.h|  1 +
 drivers/mtd/nand/raw/denali_dt.c | 10 +++---
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 15e90291de09..ab91db85467d 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1220,6 +1220,17 @@ static int denali_multidev_fixup(struct denali_nand_info 
*denali)
return 0;
 }
 
+int denali_wait_reset_complete(struct denali_nand_info *denali)
+{
+   u32 irq_status;
+
+   irq_status = denali_wait_for_irq(denali, INTR__RST_COMP);
+   if (!(irq_status & INTR__RST_COMP))
+   return -EIO;
+
+   return 0;
+}
+
 int denali_init(struct denali_nand_info *denali)
 {
struct nand_chip *chip = >nand;
diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
index 019deda094e5..6cd02b2e26ee 100644
--- a/drivers/mtd/nand/raw/denali.h
+++ b/drivers/mtd/nand/raw/denali.h
@@ -321,6 +321,7 @@ struct denali_nand_info {
 #define DENALI_CAP_DMA_64BIT   BIT(1)
 
 int denali_calc_ecc_bytes(int step_size, int strength);
+int denali_wait_reset_complete(struct denali_nand_info *denali);
 int denali_init(struct denali_nand_info *denali);
 
 #endif /* __DENALI_H__ */
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index 75ad15b0758c..8a6950f8a39f 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -154,10 +154,14 @@ static int denali_dt_probe(struct udevice *dev)
 
/*
 * When the reset is deasserted, the initialization sequence is
-* kicked (bootstrap process). The driver must wait until it is
-* finished. Otherwise, it will result in unpredictable 
behavior.
+* kicked. The driver must wait until it is finished. Otherwise,
+* it will result in unpredictable behavior.
 */
-   udelay(200);
+   ret = denali_wait_reset_complete(denali);
+   if (ret) {
+   dev_err(denali->dev, "reset not completed.\n");
+   return ret;
+   }
}
 
return denali_init(denali);
-- 
2.19.0



Re: [EXT] [PATCH 1/1] power: pmic_pca9450: fix PCA9450A I2C address

2020-06-29 Thread Sébastien Szymanski
On 6/29/20 11:51 AM, Ye Li wrote:
> On Mon, 2020-06-29 at 10:42 +0200, Sébastien Szymanski wrote:
>> Caution: EXT Email
>>
>> PCA9450A I2C address is 0x25. Fix it.
>>
>> Signed-off-by: Sébastien Szymanski 
>> ---
>>  drivers/power/pmic/pmic_pca9450.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/power/pmic/pmic_pca9450.c
>> b/drivers/power/pmic/pmic_pca9450.c
>> index 67a9090200..c0fb78c4cd 100644
>> --- a/drivers/power/pmic/pmic_pca9450.c
>> +++ b/drivers/power/pmic/pmic_pca9450.c
>> @@ -23,7 +23,7 @@ int power_pca9450a_init(unsigned char bus)
>> p->name = pca9450_name;
>> p->interface = PMIC_I2C;
>> p->number_of_regs = PCA9450_REG_NUM;
>> -   p->hw.i2c.addr = 0x35;
>> +   p->hw.i2c.addr = 0x25;
> 
> The address 0x35 is correct for PCA9540A. You are probably using
> PCA9540B/C which address is 0x25. If so, please
> call power_pca9450b_init.

No.
I am using a PCA9450A chip and its address is 0x25:

# i2cget -f -y 0 0x25 0x00
0x10

Moreover, the datasheet says it's 0x25. [1]

[1] https://www.nxp.com/docs/en/data-sheet/PCA9450DS.pdf

Regards,

> 
> Best regards,
> Ye Li
>> p->hw.i2c.tx_num = 1;
>> p->bus = bus;
>>
>> --
>> 2.26.2


-- 
Sébastien Szymanski, Armadeus Systems
Software engineer


[PATCH 1/2] mtd: nand: raw: denali: Assert reset before deassert

2020-06-29 Thread Ley Foon Tan
Always put the controller in reset, then take it out of reset.
This is to make sure controller always in reset state in both SPL and
proper Uboot.

This is preparation for the next patch to poll for reset completion
(rst_comp) bit after reset.

Signed-off-by: Radu Bacrau 
Signed-off-by: Ley Foon Tan 
---
 drivers/mtd/nand/raw/denali_dt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index 2728e8098faa..75ad15b0758c 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -148,6 +148,8 @@ static int denali_dt_probe(struct udevice *dev)
if (ret) {
dev_warn(dev, "Can't get reset: %d\n", ret);
} else {
+   reset_assert_bulk();
+   udelay(2);
reset_deassert_bulk();
 
/*
-- 
2.19.0



Re: [EXT] [PATCH 1/1] power: pmic_pca9450: fix PCA9450A I2C address

2020-06-29 Thread Ye Li
On Mon, 2020-06-29 at 10:42 +0200, Sébastien Szymanski wrote:
> Caution: EXT Email
> 
> PCA9450A I2C address is 0x25. Fix it.
> 
> Signed-off-by: Sébastien Szymanski 
> ---
>  drivers/power/pmic/pmic_pca9450.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/pmic/pmic_pca9450.c
> b/drivers/power/pmic/pmic_pca9450.c
> index 67a9090200..c0fb78c4cd 100644
> --- a/drivers/power/pmic/pmic_pca9450.c
> +++ b/drivers/power/pmic/pmic_pca9450.c
> @@ -23,7 +23,7 @@ int power_pca9450a_init(unsigned char bus)
> p->name = pca9450_name;
> p->interface = PMIC_I2C;
> p->number_of_regs = PCA9450_REG_NUM;
> -   p->hw.i2c.addr = 0x35;
> +   p->hw.i2c.addr = 0x25;

The address 0x35 is correct for PCA9540A. You are probably using
PCA9540B/C which address is 0x25. If so, please
call power_pca9450b_init.

Best regards,
Ye Li
> p->hw.i2c.tx_num = 1;
> p->bus = bus;
> 
> --
> 2.26.2
> 

[PATCH 4/6] mmc: mmc_spi: Read R2 response for send status command - CMD13

2020-06-29 Thread Pragnesh Patel
Send status command (CMD13) will send R1 response under SD mode
but R2 response under SPI mode.

R2 response is 2 bytes long, so read 2 bytes for mmc SPI mode

Signed-off-by: Pragnesh Patel 
---
 drivers/mmc/mmc_spi.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 18d36878ef..ee56de36ec 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -266,7 +266,7 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
u8 *resp = NULL;
u32 resp_size = 0;
bool resp_match = false;
-   u8 resp8 = 0, resp40[5] = { 0 }, resp_match_value = 0;
+   u8 resp8 = 0, resp16[2] = { 0 }, resp40[5] = { 0 }, resp_match_value = 
0;
 
dm_spi_claim_bus(dev);
 
@@ -291,6 +291,9 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
resp_size = sizeof(resp40);
break;
case MMC_CMD_SEND_STATUS:
+   resp = (u8 *)[0];
+   resp_size = sizeof(resp16);
+   break;
case MMC_CMD_SET_BLOCKLEN:
case MMC_CMD_SPI_CRC_ON_OFF:
case MMC_CMD_STOP_TRANSMISSION:
@@ -335,8 +338,10 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
cmd->response[0] |= (uint)resp40[1] << 24;
break;
case MMC_CMD_SEND_STATUS:
-   cmd->response[0] = (resp8 & 0xff) ?
-   MMC_STATUS_ERROR : MMC_STATUS_RDY_FOR_DATA;
+   if (resp16[0] || resp16[1])
+   cmd->response[0] = MMC_STATUS_ERROR;
+   else
+   cmd->response[0] = MMC_STATUS_RDY_FOR_DATA;
break;
case MMC_CMD_SEND_CID:
case MMC_CMD_SEND_CSD:
-- 
2.17.1



[PATCH 2/6] mmc: mmc_spi: generate R1 response for different mmc SPI commands

2020-06-29 Thread Pragnesh Patel
R1 response is 1 byte long for mmc SPI commands as per the updated
physical layer specification version 7.10.

So correct the resp and resp_size for existing commands

Signed-off-by: Pragnesh Patel 
---
 drivers/mmc/mmc_spi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 86cc932151..ddfebb6ed6 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -305,6 +305,8 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
case MMC_CMD_READ_MULTIPLE_BLOCK:
case MMC_CMD_WRITE_SINGLE_BLOCK:
case MMC_CMD_WRITE_MULTIPLE_BLOCK:
+   resp = 
+   resp_size = sizeof(resp8);
break;
default:
resp = 
-- 
2.17.1



[PATCH 3/6] mmc: read ssr for SD spi

2020-06-29 Thread Pragnesh Patel
The content of ssr is useful only for erase operations.
This saves erase time.

Signed-off-by: Pragnesh Patel 
Reviewed-by: Bin Meng 
---
 drivers/mmc/mmc.c | 5 +
 drivers/mmc/mmc_spi.c | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 620bb93064..6b193d6d70 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1746,6 +1746,11 @@ static int sd_select_mode_and_width(struct mmc *mmc, 
uint card_caps)
mmc_set_bus_width(mmc, 1);
mmc_select_mode(mmc, MMC_LEGACY);
mmc_set_clock(mmc, mmc->tran_speed, MMC_CLK_ENABLE);
+#if CONFIG_IS_ENABLED(MMC_WRITE)
+   err = sd_read_ssr(mmc);
+   if (err)
+   pr_warn("unable to read ssr\n");
+#endif
return 0;
}
 
diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index ddfebb6ed6..18d36878ef 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -305,6 +305,7 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
case MMC_CMD_READ_MULTIPLE_BLOCK:
case MMC_CMD_WRITE_SINGLE_BLOCK:
case MMC_CMD_WRITE_MULTIPLE_BLOCK:
+   case MMC_CMD_APP_CMD:
resp = 
resp_size = sizeof(resp8);
break;
-- 
2.17.1



[PATCH 6/6] mmc_spi: generate R1b response for erase and stop transmission command

2020-06-29 Thread Pragnesh Patel
As per the SD physical layer specification version 7.10, erase
command (CMD38) and stop transmission command (CMD12) will generate
R1b response.

R1b = R1 + busy signal

A non-zero value after the R1 response indicates card is ready for
next command.

Signed-off-by: Pragnesh Patel 
---
 drivers/mmc/mmc_spi.c | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 96a41076dc..50fcd32674 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -59,6 +59,7 @@
 #define CMD_TIMEOUT8
 #define READ_TIMEOUT   300 /* 1 sec */
 #define WRITE_TIMEOUT  300 /* 1 sec */
+#define R1B_TIMEOUT300 /* 1 sec */
 
 struct mmc_spi_plat {
struct mmc_config cfg;
@@ -72,7 +73,7 @@ struct mmc_spi_priv {
 static int mmc_spi_sendcmd(struct udevice *dev,
   ushort cmdidx, u32 cmdarg, u32 resp_type,
   u8 *resp, u32 resp_size,
-  bool resp_match, u8 resp_match_value)
+  bool resp_match, u8 resp_match_value, bool r1b)
 {
int i, rpos = 0, ret = 0;
u8 cmdo[7], r;
@@ -133,6 +134,24 @@ static int mmc_spi_sendcmd(struct udevice *dev,
resp[i] = r;
}
 
+   if (r1b == true) {
+   i = R1B_TIMEOUT;
+   while (i) {
+   ret = dm_spi_xfer(dev, 1 * 8, NULL, , 0);
+   if (ret)
+   return ret;
+
+   debug(" resp%d=0x%x", rpos, r);
+   rpos++;
+   i--;
+
+   if (r)
+   break;
+   }
+   if (!i)
+   return -ETIMEDOUT;
+   }
+
debug("\n");
 
return 0;
@@ -265,7 +284,7 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
int i, multi, ret = 0;
u8 *resp = NULL;
u32 resp_size = 0;
-   bool resp_match = false;
+   bool resp_match = false, r1b = false;
u8 resp8 = 0, resp16[2] = { 0 }, resp40[5] = { 0 }, resp_match_value = 
0;
 
dm_spi_claim_bus(dev);
@@ -296,12 +315,17 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
break;
case MMC_CMD_SET_BLOCKLEN:
case MMC_CMD_SPI_CRC_ON_OFF:
-   case MMC_CMD_STOP_TRANSMISSION:
resp = 
resp_size = sizeof(resp8);
resp_match = true;
resp_match_value = 0x0;
break;
+   case MMC_CMD_STOP_TRANSMISSION:
+   case MMC_CMD_ERASE:
+   resp = 
+   resp_size = sizeof(resp8);
+   r1b = true;
+   break;
case MMC_CMD_SEND_CSD:
case MMC_CMD_SEND_CID:
case MMC_CMD_READ_SINGLE_BLOCK:
@@ -323,7 +347,7 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
};
 
ret = mmc_spi_sendcmd(dev, cmd->cmdidx, cmd->cmdarg, cmd->resp_type,
- resp, resp_size, resp_match, resp_match_value);
+ resp, resp_size, resp_match, resp_match_value, 
r1b);
if (ret)
goto done;
 
-- 
2.17.1



[PATCH 5/6] mmc: mmc_spi: Generate R1 response for erase block start and end address

2020-06-29 Thread Pragnesh Patel
Erase block start address (CMD32) and erase block end address (CMD33)
command will generate R1 response for mmc SPI mode.

R1 response is 1 byte long for mmc SPI, so assign 1 byte as a response
for this commands.

Signed-off-by: Pragnesh Patel 
---
 drivers/mmc/mmc_spi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index ee56de36ec..96a41076dc 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -309,6 +309,8 @@ static int dm_mmc_spi_request(struct udevice *dev, struct 
mmc_cmd *cmd,
case MMC_CMD_WRITE_SINGLE_BLOCK:
case MMC_CMD_WRITE_MULTIPLE_BLOCK:
case MMC_CMD_APP_CMD:
+   case SD_CMD_ERASE_WR_BLK_START:
+   case SD_CMD_ERASE_WR_BLK_END:
resp = 
resp_size = sizeof(resp8);
break;
-- 
2.17.1



[PATCH 0/6] mmc_spi: mmc erase resolve

2020-06-29 Thread Pragnesh Patel
Earlier "mmc erase " command reorts Ok but not actually erase the contents
of some SD cards. This series will resolve this issue.

There is still 1 limitation for some SDHC mmc_spi cards:
"mmc erase *blk#* cnt" can not erase only 1 block that means:

=> mmc erase 0x22 1

will not erase the contents of SD card. User has to erase multiple blocks at a 
time that means:

=> mmc erase 0x22 2

will erase the contents of SD card.

This limitation is from micro SD card side, i found this limitation
in Strontium micro SDHC - 4 GB (class 6).


Pragnesh Patel (6):
  mmc: mmc_spi: correct the while condition
  mmc: mmc_spi: generate R1 response for different mmc SPI commands
  mmc: read ssr for SD spi
  mmc: mmc_spi: Read R2 response for send status command - CMD13
  mmc: mmc_spi: Generate R1 response for erase block start and end
address
  mmc_spi: generate R1b response for erase and stop transmission command

 drivers/mmc/mmc.c |  5 +
 drivers/mmc/mmc_spi.c | 52 ---
 2 files changed, 49 insertions(+), 8 deletions(-)

-- 
2.17.1



[PATCH 1/6] mmc: mmc_spi: correct the while condition

2020-06-29 Thread Pragnesh Patel
When variable i will become 0, while(i--) loop breaks but variable i will
again decrement to -1 because of i-- and that's why below condition
"if (!i && (r != resp_match_value)" will never execute, So doing "i--"
inside of while() loop solves this problem.

Signed-off-by: Pragnesh Patel 
Reviewed-by: Bin Meng 
---
 drivers/mmc/mmc_spi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index e76ab54838..86cc932151 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -105,12 +105,14 @@ static int mmc_spi_sendcmd(struct udevice *dev,
if (resp_match) {
r = ~resp_match_value;
i = CMD_TIMEOUT;
-   while (i--) {
+   while (i) {
ret = dm_spi_xfer(dev, 1 * 8, NULL, , 0);
if (ret)
return ret;
debug(" resp%d=0x%x", rpos, r);
rpos++;
+   i--;
+
if (r == resp_match_value)
break;
}
-- 
2.17.1



[PATCH] usb: host: dwc3-sti-glue: Fix ofnode_valid() parameter

2020-06-29 Thread Patrice Chotard
node varaible is used as iterator into ofnode_for_each_subnode()
loop, when exiting of it, node is no more a valid ofnode.
Use dwc3_node instead as parameter of ofnode_valid()

Fixes: ac28e59a574d ("usb: Migrate to support live DT for some driver")
Signed-off-by: Patrice Chotard 
---

 drivers/usb/host/dwc3-sti-glue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/dwc3-sti-glue.c b/drivers/usb/host/dwc3-sti-glue.c
index a72ab20168..3e6c1429d6 100644
--- a/drivers/usb/host/dwc3-sti-glue.c
+++ b/drivers/usb/host/dwc3-sti-glue.c
@@ -159,7 +159,7 @@ static int sti_dwc3_glue_bind(struct udevice *dev)
dwc3_node = node;
}
 
-   if (!ofnode_valid(node)) {
+   if (!ofnode_valid(dwc3_node)) {
pr_err("Can't find dwc3 subnode for %s\n", dev->name);
return -ENODEV;
}
-- 
2.17.1



Fwd: [PATCH 1/1] riscv: use log functions in fdt_fixup

2020-06-29 Thread Heinrich Schuchardt
 Forwarded Message 
Subject: Re: [PATCH 1/1] riscv: use log functions in fdt_fixup
Date: Mon, 29 Jun 2020 15:21:43 +0800
From: Leo Liang 
To: Heinrich Schuchardt 

On Fri, Jun 26, 2020 at 06:34:43AM +0200, Heinrich Schuchardt wrote:
> Replace printf() and debug() by log_err() and log_debug().
>
> "No reserved memory region found in source FDT\n" is not an error but a
> debug information.
>
> %s/can not/cannot/ - use the more common spelling.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/riscv/lib/fdt_fixup.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>

Reviewed-by: Leo Liang 

> diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> index 6db48ad04a..c1dc247cf7 100644
> --- a/arch/riscv/lib/fdt_fixup.c
> +++ b/arch/riscv/lib/fdt_fixup.c
> @@ -37,7 +37,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
>
>   offset = fdt_path_offset(src, "/reserved-memory");
>   if (offset < 0) {
> - printf("No reserved memory region found in source FDT\n");
> + log_debug("No reserved memory region found in source FDT\n");
>   return 0;
>   }
>
> @@ -48,7 +48,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
> "reg", 0, ,
> false);
>   if (addr == FDT_ADDR_T_NONE) {
> - debug("failed to read address/size for %s\n", name);
> + log_debug("failed to read address/size for %s\n", name);
>   continue;
>   }
>   strncpy(basename, name, max_len);
> @@ -63,7 +63,7 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void *dst)
>   err = fdtdec_add_reserved_memory(dst, basename, _mem,
>);
>   if (err < 0) {
> - printf("failed to add reserved memory: %d\n", err);
> + log_err("failed to add reserved memory: %d\n", err);
>   return err;
>   }
>   if (!fdt_getprop(src, node, "no-map", NULL))
> @@ -109,7 +109,7 @@ int board_fix_fdt(void *fdt)
>
>   err = riscv_board_reserved_mem_fixup(fdt);
>   if (err < 0) {
> - printf("failed to fixup DT for reserved memory: %d\n", err);
> + log_err("failed to fixup DT for reserved memory: %d\n", err);
>   return err;
>   }
>
> @@ -127,14 +127,14 @@ int arch_fixup_fdt(void *blob)
>   size = fdt_totalsize(blob);
>   err  = fdt_open_into(blob, blob, size + 32);
>   if (err < 0) {
> - printf("Device Tree can't be expanded to accommodate new node");
> + log_err("Device Tree can't be expanded to accommodate new 
> node");
>   return err;
>   }
>   chosen_offset = fdt_path_offset(blob, "/chosen");
>   if (chosen_offset < 0) {
>   err = fdt_add_subnode(blob, 0, "chosen");
>   if (err < 0) {
> - printf("chosen node can not be added\n");
> + log_err("chosen node cannot be added\n");
>   return err;
>   }
>   }
> --
> 2.27.0
>


Re: [PATCH 2/7] usb: ehci-mx6: Add i.MX8 OTG controller support

2020-06-29 Thread Marek Vasut
On 6/29/20 10:24 AM, Peng Fan wrote:

[...]

>>> The i.MX8 has two USB controllers: USBOH and USB3. The USBOH reuses
>>> previous i.MX6/7. It has same PHY IP as i.MX7ULP but NC registers are
>>> same as i.MX7D. So add its support in ehci-mx6 driver.
>>>
>>> Also the driver is updated to remove build warning for 64 bits CPU.
>>
>> Please split the fixes into separate patch.
> 
> Sorry for not be clear, but the driver was only built for ARM32 i.MX.
> It is after we start supporting i.MX8, there are some warnings, which
> was introduced by adding i.MX8 support. It should stay in same patch.

I understand that, but the 64bit fixes can be pulled into separate patch
to make it easier to review just the OTG support without having the
fixes mixed in the same patch.

[...]

>>>  static void usb_power_config(int index)  {
>>> -   struct usbnc_regs *usbnc = (struct usbnc_regs *)(USB_BASE_ADDR +
>>> +   struct usbnc_regs *usbnc = (struct usbnc_regs
>>> +*)(ulong)(USB_BASE_ADDR +
>>
>> Is the extra type cast really needed ? If so, then it should be uintptr_t so 
>> it
>> would work with 64bit addresses.
> 
> Will use uintptr_t. there is warning if not.
> 
> "warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]"

[...]


[PATCH 1/1] power: pmic_pca9450: fix PCA9450A I2C address

2020-06-29 Thread Sébastien Szymanski
PCA9450A I2C address is 0x25. Fix it.

Signed-off-by: Sébastien Szymanski 
---
 drivers/power/pmic/pmic_pca9450.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/pmic/pmic_pca9450.c 
b/drivers/power/pmic/pmic_pca9450.c
index 67a9090200..c0fb78c4cd 100644
--- a/drivers/power/pmic/pmic_pca9450.c
+++ b/drivers/power/pmic/pmic_pca9450.c
@@ -23,7 +23,7 @@ int power_pca9450a_init(unsigned char bus)
p->name = pca9450_name;
p->interface = PMIC_I2C;
p->number_of_regs = PCA9450_REG_NUM;
-   p->hw.i2c.addr = 0x35;
+   p->hw.i2c.addr = 0x25;
p->hw.i2c.tx_num = 1;
p->bus = bus;
 
-- 
2.26.2



[PATCH] board: st: move type-c stusb1600 controller code in a driver

2020-06-29 Thread Patrick Delaunay
Migrate the ST Microelectronics STUSB160X Type-C controller code in
a generic I2C driver in st/common, based on Linux one in :
drivers/usb/typec/stusb160x.c

This patch simplifies the stm32mp1 board code and allows to reuse
this STUSB160X driver in other boards.

Signed-off-by: Patrick Delaunay 
---

 board/st/common/Kconfig |  7 
 board/st/common/Makefile|  2 +
 board/st/common/stusb160x.c | 46 +++
 board/st/common/stusb160x.h | 10 +
 board/st/stm32mp1/stm32mp1.c| 58 +++--
 configs/stm32mp15_basic_defconfig   |  1 +
 configs/stm32mp15_trusted_defconfig |  1 +
 7 files changed, 73 insertions(+), 52 deletions(-)
 create mode 100644 board/st/common/stusb160x.c
 create mode 100644 board/st/common/stusb160x.h

diff --git a/board/st/common/Kconfig b/board/st/common/Kconfig
index 015ba40939..5280d0f9ed 100644
--- a/board/st/common/Kconfig
+++ b/board/st/common/Kconfig
@@ -69,3 +69,10 @@ config DFU_ALT_RAM0
depends on ARCH_STM32MP && SET_DFU_ALT_INFO
help
  This defines the partitions of ram used to build dfu dynamically.
+
+config TYPEC_STUSB160X
+   tristate "STMicroelectronics STUSB160X Type-C controller driver"
+   depends on DM_I2C
+   help
+ Say Y if your system has STMicroelectronics STUSB160X Type-C port
+ controller.
diff --git a/board/st/common/Makefile b/board/st/common/Makefile
index aa030bacd8..1a5280e139 100644
--- a/board/st/common/Makefile
+++ b/board/st/common/Makefile
@@ -9,3 +9,5 @@ ifeq ($(CONFIG_ARCH_STM32MP),y)
 obj-$(CONFIG_SYS_MTDPARTS_RUNTIME) += stm32mp_mtdparts.o
 obj-$(CONFIG_SET_DFU_ALT_INFO) += stm32mp_dfu.o
 endif
+
+obj-$(CONFIG_TYPEC_STUSB160X) += stusb160x.o
diff --git a/board/st/common/stusb160x.c b/board/st/common/stusb160x.c
new file mode 100644
index 00..f1197f9faa
--- /dev/null
+++ b/board/st/common/stusb160x.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * STMicroelectronics STUSB Type-C controller driver
+ * based on Linux drivers/usb/typec/stusb160x.c
+ *
+ * Copyright (C) 2020, STMicroelectronics - All Rights Reserved
+ */
+
+#include 
+#include 
+#include 
+
+/* REGISTER */
+#define STUSB160X_CC_CONNECTION_STATUS 0x0E
+
+/* STUSB160X_CC_CONNECTION_STATUS bitfields */
+#define STUSB160X_CC_ATTACHBIT(0)
+
+int stusb160x_cable_connected(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   ret = uclass_get_device_by_driver(UCLASS_I2C_GENERIC,
+ DM_GET_DRIVER(stusb160x),
+ );
+   if (ret < 0)
+   return ret;
+
+   ret = dm_i2c_reg_read(dev, STUSB160X_CC_CONNECTION_STATUS);
+   if (ret < 0)
+   return 0;
+
+   return ret & STUSB160X_CC_ATTACH;
+}
+
+static const struct udevice_id stusb160x_ids[] = {
+   { .compatible = "st,stusb1600" },
+   {}
+};
+
+U_BOOT_DRIVER(stusb160x) = {
+   .name = "stusb160x",
+   .id = UCLASS_I2C_GENERIC,
+   .of_match = stusb160x_ids,
+};
diff --git a/board/st/common/stusb160x.h b/board/st/common/stusb160x.h
new file mode 100644
index 00..fe39840b41
--- /dev/null
+++ b/board/st/common/stusb160x.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020, STMicroelectronics
+ */
+
+#ifdef CONFIG_TYPEC_STUSB160X
+int stusb160x_cable_connected(void);
+#else
+int stusb160x_cable_connected(void) { return -ENODEV; }
+#endif
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 4553329b25..a257375807 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -41,6 +41,8 @@
 #include 
 #include 
 
+#include "../../st/common/stusb160x.h"
+
 /* SYSCFG registers */
 #define SYSCFG_BOOTR   0x00
 #define SYSCFG_PMCSETR 0x04
@@ -175,64 +177,16 @@ static void board_key_check(void)
 }
 
 #if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)
-
-/* STMicroelectronics STUSB1600 Type-C controller */
-#define STUSB1600_CC_CONNECTION_STATUS 0x0E
-
-/* STUSB1600_CC_CONNECTION_STATUS bitfields */
-#define STUSB1600_CC_ATTACHBIT(0)
-
-static int stusb1600_init(struct udevice **dev_stusb1600)
-{
-   ofnode node;
-   struct udevice *dev, *bus;
-   int ret;
-   u32 chip_addr;
-
-   *dev_stusb1600 = NULL;
-
-   /* if node stusb1600 is present, means DK1 or DK2 board */
-   node = ofnode_by_compatible(ofnode_null(), "st,stusb1600");
-   if (!ofnode_valid(node))
-   return -ENODEV;
-
-   ret = ofnode_read_u32(node, "reg", _addr);
-   if (ret)
-   return -EINVAL;
-
-   ret = uclass_get_device_by_ofnode(UCLASS_I2C, ofnode_get_parent(node),
- );
-   if (ret) {
-   printf("bus for stusb1600 not found\n");
-   return -ENODEV;
-   }
-
-   

RE: [PATCH 2/7] usb: ehci-mx6: Add i.MX8 OTG controller support

2020-06-29 Thread Peng Fan
> Subject: Re: [PATCH 2/7] usb: ehci-mx6: Add i.MX8 OTG controller support
> 
> On 6/29/20 4:13 AM, Peng Fan wrote:
> 
> Hi,
> 
> > The i.MX8 has two USB controllers: USBOH and USB3. The USBOH reuses
> > previous i.MX6/7. It has same PHY IP as i.MX7ULP but NC registers are
> > same as i.MX7D. So add its support in ehci-mx6 driver.
> >
> > Also the driver is updated to remove build warning for 64 bits CPU.
> 
> Please split the fixes into separate patch.

Sorry for not be clear, but the driver was only built for ARM32 i.MX.
It is after we start supporting i.MX8, there are some warnings, which
was introduced by adding i.MX8 support. It should stay in same patch.

> 
> > --- a/drivers/usb/host/ehci-mx6.c
> > +++ b/drivers/usb/host/ehci-mx6.c
> > @@ -62,12 +62,20 @@ DECLARE_GLOBAL_DATA_PTR;
> >  #define UCTRL_OVER_CUR_POL (1 << 8) /* OTG Polarity of Overcurrent
> */
> >  #define UCTRL_OVER_CUR_DIS (1 << 7) /* Disable OTG Overcurrent
> Detection */
> >
> > +#define PLL_USB_EN_USB_CLKS_MASK   (0x01 << 6)
> > +#define PLL_USB_PWR_MASK   (0x01 << 12)
> > +#define PLL_USB_ENABLE_MASK(0x01 << 13)
> > +#define PLL_USB_BYPASS_MASK(0x01 << 16)
> > +#define PLL_USB_REG_ENABLE_MASK(0x01 << 21)
> > +#define PLL_USB_DIV_SEL_MASK   (0x07 << 22)
> > +#define PLL_USB_LOCK_MASK  (0x01 << 31)
> 
> Use BIT() macro

Yes.

> 
> >  /* USBCMD */
> >  #define UCMD_RUN_STOP   (1 << 0) /* controller run/stop */
> >  #define UCMD_RESET (1 << 1) /* controller reset */
> >
> > -#if defined(CONFIG_MX6) || defined(CONFIG_MX7ULP) -static const
> > unsigned phy_bases[] = {
> > +#if defined(CONFIG_MX6) || defined(CONFIG_MX7ULP) ||
> > +defined(CONFIG_IMX8) static const ulong phy_bases[] = {
> > USB_PHY0_BASE_ADDR,
> >  #if defined(USB_PHY1_BASE_ADDR)
> > USB_PHY1_BASE_ADDR,
> > @@ -101,6 +109,53 @@ static void usb_power_config(int index)
> >
> > scg_enable_usb_pll(true);
> >
> > +#elif defined(CONFIG_IMX8)
> 
> This function should be split into multiple, it's too long, make it a per-SoC
> function.

Ok.

> 
> > +   struct usbphy_regs __iomem *usbphy =
> > +   (struct usbphy_regs __iomem *)USB_PHY0_BASE_ADDR;
> > +   int timeout = 100;
> > +
> > +   if (index > 0)
> > +   return;
> > +
> > +   writel(ANADIG_USB2_CHRG_DETECT_EN_B |
> > +  ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B,
> > +  >usb1_chrg_detect);
> > +
> > +   if (!(readl(>usb1_pll_480_ctrl) & PLL_USB_LOCK_MASK)) {
> > +
> > +   /* Enable the regulator first */
> > +   writel(PLL_USB_REG_ENABLE_MASK,
> > +  >usb1_pll_480_ctrl_set);
> > +
> > +   /* Wait at least 25us */
> > +   udelay(25);
> > +
> > +   /* Enable the power */
> > +   writel(PLL_USB_PWR_MASK, >usb1_pll_480_ctrl_set);
> > +
> > +   /* Wait lock */
> > +   while (timeout--) {
> > +   if (readl(>usb1_pll_480_ctrl) &
> > +   PLL_USB_LOCK_MASK)
> > +   break;
> > +   udelay(10);
> > +   }
> 
> Use wait_for_bit*() here.

ok.

> 
> [...]
> 
> >  static void usb_power_config(int index)  {
> > -   struct usbnc_regs *usbnc = (struct usbnc_regs *)(USB_BASE_ADDR +
> > +   struct usbnc_regs *usbnc = (struct usbnc_regs
> > +*)(ulong)(USB_BASE_ADDR +
> 
> Is the extra type cast really needed ? If so, then it should be uintptr_t so 
> it
> would work with 64bit addresses.

Will use uintptr_t. there is warning if not.

"warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]"

Thanks,
Peng.
>  
> [...]


Re: [PATCH v2 49/49] x86: chromebook_samus_tpl: Correct the image layout

2020-06-29 Thread Bin Meng
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass  wrote:
>
> At present there is not enough space for U-Boot due to the EFI loader.
> Correct this.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add patches to partially migrate rockchip to use binman
>
>  configs/chromebook_samus_tpl_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 


Re: [PATCH v2 48/49] x86: chromebook_panther: Correct the image layout

2020-06-29 Thread Bin Meng
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass  wrote:
>
> This board does not have microcode but at present that is not supported
> by Kconfig nor the binman image layout. Fix both of these.
>
> Signed-off-by: Simon Glass 
> ---
>
> (no changes since v1)
>
>  arch/x86/Kconfig| 7 ++-
>  arch/x86/dts/u-boot.dtsi| 6 +-
>  configs/chromebox_panther_defconfig | 2 ++
>  3 files changed, 13 insertions(+), 2 deletions(-)
>

Reviewed-by: Bin Meng 


  1   2   >