Re: PINE64 Rock64 - How to get SPI driver working

2020-05-19 Thread Kamal R. Prasad
Hello,

 I want to add a helper function to uboot i.e
uboot# help
will show a list of commands. I want to add 1 for my own private command.
which file contains the list of cmd that will be displayed and the
indirection?
thanks
-kamal


On Wed, May 20, 2020 at 8:58 AM Johannes Krottmayer 
wrote:

> Hello,
>
> I just compiled U-Boot v2020.04 for a PINE64 Rock media board.
> It compiles fine without errors, but when I try to probe the
> on board flash I get an error:
>
> => sf probe
> Invalid bus 0 (err=-19)
> Failed to initialize SPI flash at 0:0 (error -19)
> =>
>
> SPI is activated in the Device-Tree blob. I also added support
> to the Rockchip SPI driver (added IDS strings for this SoC).
>
> In the device config I added the following:
>
> CONFIG_SPI=y
> CONFIG_ROCKCHIP_SPI=y
> CONFIG_SPI_FLASH=y
>
> But the driver still doesn't work. Output of DM (shortened):
>
> => dm tree
> [...]
>   spi   0  [   ]   rockchip_spi  |-- spi@ff19
>
>   spi_flash 0  [   ]   spi_flash_std |   `-- spiflash@0
> [...]
>
> What is missing? Is there a way to load driver?
>
> Any kind of help is highly appreciated.
>
> --
> Kind regards,
>
> Johannes K.
>


pull request of u-boot-fsl-qoriq for v2020.07

2020-05-19 Thread Priyanka Jain
Dear Tom,

Please find my pull-request for u-boot-fsl-qoriq/master
https://travis-ci.org/github/p-priyanka-jain/u-boot/builds


Summary
Add DM_ETH support for lx2160aqds, ls2080aqds, ls1088aqds
QSI related fixes on ls1012a, ls2080a, ls1046a, ls1088a, ls1043a based platforms
Bug-fixes/updtaes related to ls1046afrwy, fsl-mc, msi-map property

Priyanka
-
The following changes since commit ed9a3aa6452f57af65eb74f73bd2a54c3a2f4b03:

  Merge tag 'efi-2020-07-rc3' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-05-18 08:17:29 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git HEAD

for you to fetch changes up to 13bc860727ee406f073c8176dd2d6b9dacf35443:

  configs: ls2080aqds_tfa_defconfig: enable DM_ETH and related (2020-05-19 
09:22:08 +0530)


Ashish Kumar (1):
  configs: ls1012a: Reduce CONFIG_ENV_SIZE to 0x2000

Ioana Ciornei (12):
  arm: dts: lx2160a: add noted for dpmacs 1, 2, 5-6
  arm: dts: lx2160aqds: add MDIO slots
  arm: dts: lx2160aqds: add nodes describing possible mezzanine cards
  board: lx2160aqds: transition to DM_ETH
  board: lx2160aqds: implement board_fit_config_name_match
  configs: lx2160aqds_tfa_defconfig: enable DM_ETH and related
  arm: dts: ls1088aqds: add CONFIG_MULTI_DTB_FIT support
  board: ls1088aqds: transition to DM_ETH
  configs: ls1088aqds_tfa_defconfig: enable DM_ETH and related
  board: ls2080aqds: transition to DM_ETH
  arm: dts: ls2080aqds: add CONFIG_MULTI_DTB_FIT support
  configs: ls2080aqds_tfa_defconfig: enable DM_ETH and related

Kuldeep Singh (13):
  treewide: Remove unused FSL QSPI config options for Layerscape platforms
  configs: ls1043a: Move CONFIG_FSL_QSPI and SPI_FLASH_SPANSION to defconfig
  configs: ls1012a: Enable CONFIG_SPI_FLASH_SPANSION in defconfigs
  configs: ls1046a: Move SPI_FLASH_SPANSION to defconfig
  treewide: Update fsl qspi node dt properties as per spi-mem driver
  configs: ls1088a: Correct ENV_ADDR value
  configs: ls2080a: Correct ENV_ADDR value
  configs: ls1046a: Define ENV_ADDR value
  configs: ls2080ardb: Make MC_INIT access flash memory as per spi-mem
  configs: ls2080ardb: Make BOOT command access flash memory as per spi-mem
 configs: ls1012a: Increase CONFIG_SYS_MALLOC_LEN size
  configs: nxp: Enable CONFIG_SYS_RELOC_GD_ENV_ADDR
  configs: ls1012a: Unset ENV_ADDR value

Laurentiu Tudor (1):
  drivers: net: fsl-mc: fixup msi-map property

Madalin Bucur (1):
  driver: net: fm: minor fix in DM ETH support

Pankit Garg (1):
  board_r: Detect ifc-nor flash at run-time

Pramod Kumar (1):
  include/configs: ls1046afrwy: add support for boot targets.

Razvan Ionut Cirjan (1):
  net: fsl-mc: fixup DPC: add /board/ports node if missing

arch/arm/dts/Makefile |  13 +-
arch/arm/dts/fsl-ls1012a-2g5rdb.dts   |   5 +-
arch/arm/dts/fsl-ls1012a-frdm.dtsi|   5 +-
arch/arm/dts/fsl-ls1012a-qds.dtsi |   5 +-
arch/arm/dts/fsl-ls1012a-rdb.dtsi |   5 +-
arch/arm/dts/fsl-ls1012a.dtsi |   4 +-
arch/arm/dts/fsl-ls1043a-qds.dtsi |   5 +-
arch/arm/dts/fsl-ls1043a.dtsi |   6 +-
arch/arm/dts/fsl-ls1046a-frwy.dts |   5 +-
arch/arm/dts/fsl-ls1046a-qds.dtsi |   5 +-
arch/arm/dts/fsl-ls1046a-rdb.dts  |   5 +-
arch/arm/dts/fsl-ls1046a.dtsi |   4 +-
arch/arm/dts/fsl-ls1088a-qds-21-x.dts |  16 ++
arch/arm/dts/fsl-ls1088a-qds-29-x.dts |  16 ++
arch/arm/dts/fsl-ls1088a-qds-sd1-21.dtsi  |  30 
arch/arm/dts/fsl-ls1088a-qds-sd1-29.dtsi  |  18 +++
arch/arm/dts/fsl-ls1088a-qds.dts  | 124 +--
arch/arm/dts/fsl-ls1088a-qds.dtsi | 186 ++
arch/arm/dts/fsl-ls1088a-rdb.dts  |   5 +-
arch/arm/dts/fsl-ls1088a.dtsi |   2 +-
arch/arm/dts/fsl-ls2080a-qds-42-x.dts |  16 ++
arch/arm/dts/fsl-ls2080a-qds-sd1-42.dtsi  |  48 ++
arch/arm/dts/fsl-ls2080a-qds.dts  |  73 +
arch/arm/dts/fsl-ls2080a-qds.dtsi |  77 +
arch/arm/dts/fsl-ls2080a.dtsi |   4 +-
arch/arm/dts/fsl-ls2088a-rdb-qspi.dts |   5 +-
arch/arm/dts/fsl-lx2160a-qds-19-11-x.dts  |  19 +++
arch/arm/dts/fsl-lx2160a-qds-19-x-x.dts   |  17 ++
arch/arm/dts/fsl-lx2160a-qds-20-11-x.dts  |  19 +++
arch/arm/dts/fsl-lx2160a-qds-20-x-x.dts   |  17 ++
arch/arm/dts/fsl-lx2160a-qds-3-11-x.dts   |  19 +++
arch/arm/dts/fsl-lx2160a-qds-3-x-x.dts|  17 ++
arch/arm/dts/fsl-lx2160a-qds-7-11-x.dts   |  19 +++
arch/arm/dts/fsl-lx2160a-qds-7-x-x.dts   

Re: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc

2020-05-19 Thread Rayagonda Kokatanur
Hi Thomas,

On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons  wrote:
>
> Rayagonda Kokatanur  writes:
>
> > On Tue, May 19, 2020 at 11:01 PM Tom Rini  wrote:
> >>
> >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
> >> > Hi Tom,
> >> >
> >> >
> >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini  wrote:
> >> > >
> >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
> >> > >
> >> > > > This is the second patch set series prepared on top of the
> >> > > > first patch set ("add initial support for broadcom NS3 soc").
> >> > > >
> >> > > > This patch set will add following,
> >> > > > -dt nodes and defconfig options for basic device like pinctrl,
> >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> >> > > > -start wdt service
> >> > > > -Enable GPT commands
> >> > > > -Enable EXT4 and FAT fs support
> >> > >
> >> > > All of the dts changes not in a -u-boot.dtsi file either come from
> >> > > mainline Linux or at least linux-next and have had some level upstream
> >> > > review, right?  Thanks!
> >> >
> >> > Yes. All the DTS changes are merged in the Linux and are available at
> >> > arch/arm64/boot/dts/broadcom/stingray/
> >>
> >> Great.  Please reference the release you're taking these from as that
> >> will make future resyncs easier.  Thanks!
> >
> > It's Linux v5.6.
>
> What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> looked at the mainline Linux device trees and I couldn't easily see the
> correspondence.  Will the renaming complicate synchronization?

Do we need to maintain the same dt file between linux and uboot ?
Also in uboot we don't enable all devices,  how do we handle this ?
Please let me know.

Best regards,
Rayagonda

>
> Thomas


Re: [PATCH v10 17/18] configs: fu540: Add config options for U-Boot SPL

2020-05-19 Thread Bin Meng
Hi Jagan,

On Wed, May 20, 2020 at 12:11 AM Jagan Teki  wrote:
>
> On Sat, May 16, 2020 at 11:42 AM Pragnesh Patel
>  wrote:
> >
> > Hi Jagan,
> >
> > >-Original Message-
> > >From: Jagan Teki 
> > >Sent: 15 May 2020 23:05
> > >To: Pragnesh Patel 
> > >Cc: U-Boot-Denx ; Atish Patra
> > >; Palmer Dabbelt ; Bin
> > >Meng ; Paul Walmsley ;
> > >Anup Patel ; Sagar Kadam
> > >; Rick Chen ; Palmer
> > >Dabbelt 
> > >Subject: Re: [PATCH v10 17/18] configs: fu540: Add config options for 
> > >U-Boot
> > >SPL
> > >
> > >[External Email] Do not click links or attachments unless you recognize the
> > >sender and know the content is safe
> > >
> > >On Thu, May 14, 2020 at 5:24 PM Pragnesh Patel
> > > wrote:
> > >>
> > >> With sifive_fu540_defconfig:
> > >>
> > >> User can use FSBL or u-boot-spl.bin anyone at a time.
> > >>
> > >> For FSBL,
> > >> fsbl->fw_payload.bin (opensbi + U-Boot)
> > >>
> > >> For u-boot-spl.bin,
> > >> u-boot-spl.bin->FIT image (opensbi + U-Boot proper + dtb)
> > >>
> > >> U-Boot SPL will be loaded by ZSBL from SD card (replace fsbl.bin with
> > >> u-boot-spl.bin) and runs in L2 LIM in machine mode and then load FIT
> > >> image u-boot.itb from SD card into RAM.
> > >>
> > >> U-Boot SPL expects u-boot.itb FIT image at the starting of SD card
> > >> sector number (0x822) of GUID type "2E54B353-1271-4842-806F-
> > >E436D6AF6985"
> > >>
> > >> Signed-off-by: Pragnesh Patel 
> > >> Signed-off-by: Jagan Teki 
> > >> Reviewed-by: Jagan Teki 
> > >> ---
> > >>  configs/sifive_fu540_defconfig |   8 ++
> > >>  doc/board/sifive/fu540.rst | 134 +
> > >>  2 files changed, 142 insertions(+)
> > >>
> > >> diff --git a/configs/sifive_fu540_defconfig
> > >> b/configs/sifive_fu540_defconfig index f805aacc7a..8d412f8d6a 100644
> > >> --- a/configs/sifive_fu540_defconfig
> > >> +++ b/configs/sifive_fu540_defconfig
> > >> @@ -1,6 +1,11 @@
> > >>  CONFIG_RISCV=y
> > >> +CONFIG_SPL_GPIO_SUPPORT=y
> > >> +CONFIG_SYS_MALLOC_F_LEN=0x3000
> > >>  CONFIG_ENV_SIZE=0x2
> > >> +CONFIG_SPL_MMC_SUPPORT=y
> > >>  CONFIG_NR_DRAM_BANKS=1
> > >> +CONFIG_SPL=y
> > >> +CONFIG_SPL_SPI_SUPPORT=y
> > >>  CONFIG_TARGET_SIFIVE_FU540=y
> > >>  CONFIG_ARCH_RV64I=y
> > >>  CONFIG_RISCV_SMODE=y
> > >> @@ -9,7 +14,10 @@ CONFIG_FIT=y
> > >>  CONFIG_MISC_INIT_R=y
> > >>  CONFIG_DISPLAY_CPUINFO=y
> > >>  CONFIG_DISPLAY_BOARDINFO=y
> > >> +CONFIG_SPL_SEPARATE_BSS=y
> > >> +CONFIG_SPL_YMODEM_SUPPORT=y
> > >>  CONFIG_OF_BOARD_FIXUP=y
> > >>  CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
> > >>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > >> +CONFIG_SPL_CLK=y
> > >>  CONFIG_DM_MTD=y
> > >> diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
> > >> index 610ba87074..89e8d66c56 100644
> > >> --- a/doc/board/sifive/fu540.rst
> > >> +++ b/doc/board/sifive/fu540.rst
> > >> @@ -31,6 +31,9 @@ TODO:
> > >>  stdout-path = "/soc/serial@1001:115200";
> > >> };
> > >>
> > >> +Booting from MMC using FSBL
> > >> +---
> > >> +
> > >>  Building
> > >>  
> > >>
> > >> @@ -421,3 +424,134 @@ as well.
> > >>
> > >> Please press Enter to activate this console.
> > >> / #
> > >> +
> > >> +Booting from MMC using U-Boot SPL
> > >> +-
> > >> +
> > >> +Building
> > >> +
> > >> +
> > >> +Before building U-Boot SPL, OpenSBI must be built first. OpenSBI can
> > >> +be cloned and built for FU540 as below:
> > >> +
> > >> +.. code-block:: console
> > >> +
> > >> +   git clone https://github.com/riscv/opensbi.git
> > >> +   cd opensbi
> > >> +   make PLATFORM=generic FW_DYNAMIC=y
> > >> +
> > >> +Copy OpenSBI FW_DYNAMIC image
> > >> +(build/platform/generic/firmware/fw_dynamic.bin) into U-Boot root
> > >> +directory
> > >> +
> > >> +.. code-block:: console
> > >> +
> > >> +   cp build/platform/generic/firmware/fw_dynamic.bin 
> > >> +
> > >> +Now build the U-Boot SPL and U-Boot proper
> > >> +
> > >> +.. code-block:: console
> > >> +
> > >> +   cd 
> > >> +   make sifive_fu540_defconfig
> > >> +   make
> > >> +
> > >> +This will generate spl/u-boot-spl.bin and FIT image (u-boot.itb)
> > >> +
> > >> +
> > >> +Flashing
> > >> +
> > >> +
> > >> +ZSBL loads the U-Boot SPL (u-boot-spl.bin) from a partition with GUID
> > >> +type
> > >> +5B193300-FC78-40CD-8002-E86C45580B47
> > >> +
> > >> +U-Boot SPL expects a U-Boot FIT image (u-boot.itb) from a partition
> > >> +with GUID type 2E54B353-1271-4842-806F-E436D6AF6985
> > >> +
> > >> +FIT image (u-boot.itb) is a combination of fw_dynamic.bin,
> > >> +u-boot-nodtb.bin and device tree blob (hifive-unleashed-a00.dtb)
> > >> +
> > >> +Format the SD card (make sure the disk has GPT, otherwise use gdisk
> > >> +to switch)
> > >> +
> > >> +.. code-block:: none
> > >> +
> > >> +   # sudo sgdisk --clear \
> > >> +   > --set-alignment=2 \
> > >> +   > --new=1:34:2081 --change-name=1:loader1 --typecode=1:5B193300-
> > >FC78-40CD-8002-E86C45580B47 

Re: rockpro64: Enable HDMI output

2020-05-19 Thread Anand Moon








On Friday, May 15, 2020, 5:28:36 PM GMT+5:30, Marcin Juszkiewicz 
 wrote: 





Enable config options and console setting like on other rk3399 boards.

---
configs/rockpro64-rk3399_defconfig | 4 
include/configs/rockpro64_rk3399.h | 5 +
2 files changed, 9 insertions(+)

diff --git configs/rockpro64-rk3399_defconfig
configs/rockpro64-rk3399_defconfig
index 8074e4665a..c815cc646d 100644
--- configs/rockpro64-rk3399_defconfig
+++ configs/rockpro64-rk3399_defconfig
@@ -58,5 +58,9 @@ CONFIG_USB_ETHER_ASIX88179=y
CONFIG_USB_ETHER_MCS7830=y
CONFIG_USB_ETHER_RTL8152=y
CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
CONFIG_SPL_TINY_MEMSET=y
CONFIG_ERRNO_STR=y
diff --git include/configs/rockpro64_rk3399.h
include/configs/rockpro64_rk3399.h
index 5f52c1e4f6..8e82131762 100644
--- include/configs/rockpro64_rk3399.h
+++ include/configs/rockpro64_rk3399.h
@@ -6,6 +6,11 @@
#ifndef __ROCKPRO64_RK3399_H
#define __ROCKPRO64_RK3399_H

+#define ROCKCHIP_DEVICE_SETTINGS \
+        "stdin=serial,usbkbd\0" \
+        "stdout=serial,vidconsole\0" \
+        "stderr=serial,vidconsole\0"
+
#include 

#define CONFIG_SYS_MMC_ENV_DEV 0
-- 
2.26.2



Re: [PATCH] ARM: add psci_arch_init() declaration for CONFIG_ARMV7_PSCI

2020-05-19 Thread Masahiro Yamada
On Wed, May 20, 2020 at 12:09 PM Simon Glass  wrote:
>
> HI Masahiro,
>
> On Tue, 19 May 2020 at 20:44, Masahiro Yamada
>  wrote:
> >
> > arch/arm/include/asm/system.h declares psci_arch_init(), but it is
> > surrounded by #ifdef CONFIG_ARMV8_PSCI.
> >
> > psci_arch_init() is called for CONFIG_ARMV7_PSCI too. Add the missing
> > function declaration.
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  arch/arm/include/asm/system.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> > index 1e3f574403..7a40b56acd 100644
> > --- a/arch/arm/include/asm/system.h
> > +++ b/arch/arm/include/asm/system.h
> > @@ -528,6 +528,7 @@ void mmu_page_table_flush(unsigned long start, unsigned 
> > long stop);
> >
> >  #ifdef CONFIG_ARMV7_PSCI
> >  void psci_arch_cpu_entry(void);
> > +void psci_arch_init(void);
>
> Could you add a function comment too?


Sorry, I can't.

It was a long time ago that I worked on the psci implementation
for my board, so I forgot what psci_arch_init() was actually intended.


I was only interested in fixing
-Wmissing-prototypes warning here.


None of the remaining functions are documented,
so "please also do this while you are here" is not
a reasonable request, I think.


If people are happy with not fixing the warning,
please feel free to ignore this patch.





> >  u32 psci_version(void);
> >  s32 psci_features(u32 function_id, u32 psci_fid);
> >  s32 psci_cpu_off(void);
> > --
> > 2.25.1
> >
>
> Regards,
> Simon



--
Best Regards
Masahiro Yamada


[PATCH 5/6] ARM: uniphier: delete or replace includes

2020-05-19 Thread Masahiro Yamada
 pulls in a lot of bloat.  is unneeded in most of
places.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/arm32/cache-uniphier.c | 1 -
 arch/arm/mach-uniphier/arm32/psci.c   | 1 -
 arch/arm/mach-uniphier/arm32/timer.c  | 2 +-
 arch/arm/mach-uniphier/arm64/mem_map.c| 1 -
 arch/arm/mach-uniphier/base-address.c | 2 +-
 arch/arm/mach-uniphier/board_late_init.c  | 1 -
 arch/arm/mach-uniphier/boards.c   | 2 +-
 arch/arm/mach-uniphier/boot-device/boot-device-ld11.c | 1 -
 arch/arm/mach-uniphier/boot-device/boot-device-ld4.c  | 1 -
 arch/arm/mach-uniphier/boot-device/boot-device-pro5.c | 1 -
 arch/arm/mach-uniphier/boot-device/boot-device-pxs2.c | 1 -
 arch/arm/mach-uniphier/boot-device/boot-device-pxs3.c | 1 -
 arch/arm/mach-uniphier/boot-device/boot-device.c  | 2 +-
 arch/arm/mach-uniphier/clk/clk-dram-ld4.c | 1 -
 arch/arm/mach-uniphier/clk/clk-dram-pxs2.c| 1 -
 arch/arm/mach-uniphier/clk/clk-early-ld4.c| 1 -
 arch/arm/mach-uniphier/clk/clk-ld11.c | 1 -
 arch/arm/mach-uniphier/clk/dpll-ld4.c | 1 -
 arch/arm/mach-uniphier/clk/dpll-pro4.c| 1 -
 arch/arm/mach-uniphier/debug-uart/debug-uart.c| 1 -
 arch/arm/mach-uniphier/dram/cmd_ddrmphy.c | 1 -
 arch/arm/mach-uniphier/dram/cmd_ddrphy.c  | 1 -
 arch/arm/mach-uniphier/dram/umc-ld4.c | 1 -
 arch/arm/mach-uniphier/dram/umc-pro4.c| 1 -
 arch/arm/mach-uniphier/dram/umc-sld8.c| 1 -
 arch/arm/mach-uniphier/dram_init.c| 2 +-
 arch/arm/mach-uniphier/fdt-fixup.c| 2 +-
 arch/arm/mach-uniphier/memconf.c  | 1 -
 arch/arm/mach-uniphier/micro-support-card.c   | 3 ++-
 arch/arm/mach-uniphier/mmc-boot-mode.c| 1 -
 arch/arm/mach-uniphier/mmc-first-dev.c| 1 -
 arch/arm/mach-uniphier/pinctrl-glue.c | 1 -
 arch/arm/mach-uniphier/reset.c| 1 -
 arch/arm/mach-uniphier/sbc/sbc-ld11.c | 1 -
 arch/arm/mach-uniphier/sbc/sbc.c  | 1 -
 arch/arm/mach-uniphier/spl_board_init.c   | 1 -
 36 files changed, 8 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-uniphier/arm32/cache-uniphier.c 
b/arch/arm/mach-uniphier/arm32/cache-uniphier.c
index b6e4abbad0..cde2a8124f 100644
--- a/arch/arm/mach-uniphier/arm32/cache-uniphier.c
+++ b/arch/arm/mach-uniphier/arm32/cache-uniphier.c
@@ -5,7 +5,6 @@
  *   Author: Masahiro Yamada 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-uniphier/arm32/psci.c 
b/arch/arm/mach-uniphier/arm32/psci.c
index b54dc3979d..a4d260aece 100644
--- a/arch/arm/mach-uniphier/arm32/psci.c
+++ b/arch/arm/mach-uniphier/arm32/psci.c
@@ -4,7 +4,6 @@
  *   Author: Masahiro Yamada 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-uniphier/arm32/timer.c 
b/arch/arm/mach-uniphier/arm32/timer.c
index b3c907b508..a40bdf1705 100644
--- a/arch/arm/mach-uniphier/arm32/timer.c
+++ b/arch/arm/mach-uniphier/arm32/timer.c
@@ -3,7 +3,7 @@
  * Copyright (C) 2012-2015 Masahiro Yamada 
  */
 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-uniphier/arm64/mem_map.c 
b/arch/arm/mach-uniphier/arm64/mem_map.c
index 7653bd2d3c..a8bd4eee89 100644
--- a/arch/arm/mach-uniphier/arm64/mem_map.c
+++ b/arch/arm/mach-uniphier/arm64/mem_map.c
@@ -3,7 +3,6 @@
  * Copyright (C) 2016 Masahiro Yamada 
  */
 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm/mach-uniphier/base-address.c 
b/arch/arm/mach-uniphier/base-address.c
index 5ee742e363..d7456f8df6 100644
--- a/arch/arm/mach-uniphier/base-address.c
+++ b/arch/arm/mach-uniphier/base-address.c
@@ -3,9 +3,9 @@
 // Copyright (C) 2019 Socionext Inc.
 //   Author: Masahiro Yamada 
 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-uniphier/board_late_init.c 
b/arch/arm/mach-uniphier/board_late_init.c
index 378aad0c9c..b800e8b8c6 100644
--- a/arch/arm/mach-uniphier/board_late_init.c
+++ b/arch/arm/mach-uniphier/board_late_init.c
@@ -5,7 +5,6 @@
  *   Author: Masahiro Yamada 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-uniphier/boards.c b/arch/arm/mach-uniphier/boards.c
index d9a8d2f28a..3e2ec9b26a 100644
--- a/arch/arm/mach-uniphier/boards.c
+++ b/arch/arm/mach-uniphier/boards.c
@@ -4,9 +4,9 @@
  *   Author: Masahiro Yamada 
  */
 
-#include 
 #include 
 #include 
+#include 
 
 #include "init.h"
 
diff --git a/arch/arm/mach-uniphier/boot-device/boot-device-ld11.c 
b/arch/arm/mach-uniphier/boot-device/boot-device-ld11.c
index 11e70a926f..4689ed79fd 100644
--- a/arch/arm/mach-uniphier/boot-device/boot-device-ld11.c
+++ b/arch/arm/mach-uniphier/boot-device/boot-device-ld11.c
@@ -4,7 +4,6 @@
  *   Author: Masahiro Yamada 
  */

[PATCH 3/6] ARM: uniphier: drop #include again from umc-pxs2.c

2020-05-19 Thread Masahiro Yamada
I do not understand the change made to this file by
commit 691d719db718 ("common: Drop init.h from common header").

  git show 691d719db718 -- arch/arm/mach-uniphier/dram/umc-pxs2.c

This file does not call or define any functions declared in 

Simply revert the change made to this file.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/dram/umc-pxs2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-uniphier/dram/umc-pxs2.c 
b/arch/arm/mach-uniphier/dram/umc-pxs2.c
index 3f7e5f30ba..24c6802a27 100644
--- a/arch/arm/mach-uniphier/dram/umc-pxs2.c
+++ b/arch/arm/mach-uniphier/dram/umc-pxs2.c
@@ -7,7 +7,6 @@
  * Copyright (C) 2015 Socionext Inc.
  */
 
-#include 
 #include 
 #include 
 #include 
-- 
2.25.1



[PATCH 1/6] ARM: uniphier: include instead of from psci.c

2020-05-19 Thread Masahiro Yamada
I do not understand the change made to this file by
commit 90526e9fbac4 ("common: Drop net.h from common header").

  git show 90526e9fbac4 -- arch/arm/mach-uniphier/arm32/psci.c

It added  while this file does not call the standard cache
functions at all.

All the uniphier-specific cache functions, uniphier_cache_*() are
declared in cache-uniphier.h, which is already included from this file.

Including  is sensible to fix the -Wmissing-prototypes
warnings because this file defines psci_cpu_on and psci_system_reset().

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/arm32/psci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-uniphier/arm32/psci.c 
b/arch/arm/mach-uniphier/arm32/psci.c
index e231e7b60b..b54dc3979d 100644
--- a/arch/arm/mach-uniphier/arm32/psci.c
+++ b/arch/arm/mach-uniphier/arm32/psci.c
@@ -6,7 +6,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -17,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../debug.h"
 #include "../soc-info.h"
-- 
2.25.1



[PATCH 6/6] ARM: uniphier: remove board_eth_init()

2020-05-19 Thread Masahiro Yamada
This platform completely migrated to CONFIG_DM_ETH.

board_eth_init() is only called from net/eth_legacy.c

Remove the legacy hook.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/micro-support-card.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/mach-uniphier/micro-support-card.c 
b/arch/arm/mach-uniphier/micro-support-card.c
index 3bd26f26db..b09ec54e1f 100644
--- a/arch/arm/mach-uniphier/micro-support-card.c
+++ b/arch/arm/mach-uniphier/micro-support-card.c
@@ -107,18 +107,6 @@ void support_card_init(void)
support_card_show_revision();
 }
 
-#if defined(CONFIG_SMC911X)
-#include 
-
-int board_eth_init(bd_t *bis)
-{
-   if (!support_card_found)
-   return 0;
-
-   return smc911x_initialize(0, (unsigned long)support_card_base + 
SMC911X_OFFSET);
-}
-#endif
-
 #if defined(CONFIG_MTD_NOR_FLASH)
 
 #include 
-- 
2.25.1



[PATCH 4/6] ARM: uniphier: drop #include again

2020-05-19 Thread Masahiro Yamada
I do not understand the changes made to these files by
commit f7ae49fc4f36 ("common: Drop log.h from common header").

  git show f7ae49fc4f36 -- arch/arm/mach-uniphier/

None of them uses the log function feature.

Simply revert the changes made to these files.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/board_init.c   | 1 -
 arch/arm/mach-uniphier/dram/ddrphy-training.c | 1 -
 arch/arm/mach-uniphier/dram/umc-pxs2.c| 1 -
 arch/arm/mach-uniphier/micro-support-card.c   | 1 -
 arch/arm/mach-uniphier/nand-reset.c   | 1 -
 5 files changed, 5 deletions(-)

diff --git a/arch/arm/mach-uniphier/board_init.c 
b/arch/arm/mach-uniphier/board_init.c
index 6bf0811edb..4f9cd6e722 100644
--- a/arch/arm/mach-uniphier/board_init.c
+++ b/arch/arm/mach-uniphier/board_init.c
@@ -5,7 +5,6 @@
  *   Author: Masahiro Yamada 
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-uniphier/dram/ddrphy-training.c 
b/arch/arm/mach-uniphier/dram/ddrphy-training.c
index c26f56367e..1decdf1cbf 100644
--- a/arch/arm/mach-uniphier/dram/ddrphy-training.c
+++ b/arch/arm/mach-uniphier/dram/ddrphy-training.c
@@ -4,7 +4,6 @@
  * Copyright (C) 2015-2016 Socionext Inc.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-uniphier/dram/umc-pxs2.c 
b/arch/arm/mach-uniphier/dram/umc-pxs2.c
index 24c6802a27..73574201e3 100644
--- a/arch/arm/mach-uniphier/dram/umc-pxs2.c
+++ b/arch/arm/mach-uniphier/dram/umc-pxs2.c
@@ -7,7 +7,6 @@
  * Copyright (C) 2015 Socionext Inc.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-uniphier/micro-support-card.c 
b/arch/arm/mach-uniphier/micro-support-card.c
index d23c0bd129..84c377766a 100644
--- a/arch/arm/mach-uniphier/micro-support-card.c
+++ b/arch/arm/mach-uniphier/micro-support-card.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-uniphier/nand-reset.c 
b/arch/arm/mach-uniphier/nand-reset.c
index dbf54aa910..11cadaabd8 100644
--- a/arch/arm/mach-uniphier/nand-reset.c
+++ b/arch/arm/mach-uniphier/nand-reset.c
@@ -4,7 +4,6 @@
  *   Author: Masahiro Yamada 
  */
 
-#include 
 #include 
 #include 
 #include 
-- 
2.25.1



[PATCH 2/6] ARM: uniphier: remove #include again from micro-support-card.c

2020-05-19 Thread Masahiro Yamada
I do not understand the changes made to this file by
commit 90526e9fbac4 ("common: Drop net.h from common header").

  git show 90526e9fbac4 -- arch/arm/mach-uniphier/micro-support-card.c

The necessary declaration is already included by  at line 112.
It also moved the  inclusion, but I do not understand the
motivation of doing so, either.

Simply revert the changes made to this file.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/micro-support-card.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-uniphier/micro-support-card.c 
b/arch/arm/mach-uniphier/micro-support-card.c
index 18435dc361..d23c0bd129 100644
--- a/arch/arm/mach-uniphier/micro-support-card.c
+++ b/arch/arm/mach-uniphier/micro-support-card.c
@@ -6,10 +6,9 @@
  */
 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
-- 
2.25.1



Re: [PING][PATCH] Optionally: Set the serial# environment variable on the i.MX7.

2020-05-19 Thread Mark G




On Mon, 11 May 2020, Stefano Babic wrote:


patch was hidden in the flood of other patches and I am unsure if this
belongs to i.MX:


No worries. To clarify the patch applies to all i.MX7 boards.


On 19.02.20 22:01, Mark G wrote:

+  Linux kernel will use this as the serial number of the machine.
+


I do not see the need of *another* CONFIG_ option. To make this
available, CONFIG_SERIAL_TAG should also be on, else you cannot call
get_board_serial() to get the serial from OCOTP. It think SET_SERIAL_ENV
is quite superflous.


The intent here is to pass in the serial number via the environemnt 
(i.e. when not using ATAGS). My patch changes the preprocessor machinery 
so that get_board_serial() is callable if this option is set.


This then lets fdt_root() put it in the FDT passed to the kernel. It also 
means that it's easily changed for testing by being in the environment. 
The origins of this patch were for a customer switching to the Meerkat96 
board that utilized the CPU serial number in Linux for provisioning and 
testing.



If this should be done global, local solution should be moved too. I
mean the warp board doing exactly this in board code.


Ah. To be fair I never looked at the port for the Warp7 board as I do not 
have one. This really should be done globally; there isn't anything board 
specific for this behavior. It should apply to all i.MX7 boards, at a 
minimum.


Well - to clarify in theory there is nothing board specific. Could there 
be a board out there with an EEPROM that contains a different serial 
number that a customer would want to pass to the kernel? Possibly but 
unlikely.



So which is the idea of this ? To move warp code and making global, or
what ?


I would say this behavior should be global but the Warp7 port seems to add 
a board specific prefix to the CPU serial number. So I am hesitant to 
remove it. If you like I can #ifdef around it.


Additionally the Warp7 code isn't quite the same as it relies on ATAGS 
being enabled where as my patch does not.


Sincerely,
Mark G.


PINE64 Rock64 - How to get SPI driver working

2020-05-19 Thread Johannes Krottmayer
Hello,

I just compiled U-Boot v2020.04 for a PINE64 Rock media board.
It compiles fine without errors, but when I try to probe the
on board flash I get an error:

=> sf probe
Invalid bus 0 (err=-19)
Failed to initialize SPI flash at 0:0 (error -19)
=>

SPI is activated in the Device-Tree blob. I also added support
to the Rockchip SPI driver (added IDS strings for this SoC).

In the device config I added the following:

CONFIG_SPI=y
CONFIG_ROCKCHIP_SPI=y
CONFIG_SPI_FLASH=y

But the driver still doesn't work. Output of DM (shortened):

=> dm tree
[...]
  spi   0  [   ]   rockchip_spi  |-- spi@ff19

  spi_flash 0  [   ]   spi_flash_std |   `-- spiflash@0
[...]

What is missing? Is there a way to load driver?

Any kind of help is highly appreciated.

-- 
Kind regards,

Johannes K.


Re: [RFC 5/6] dtoc: update dtb_platdata to support cd-gpios

2020-05-19 Thread Simon Glass
On Wed, 13 May 2020 at 14:14, Walter Lozano  wrote:
>
> Currently dtoc does not support the property cd-gpios used to declare
> the gpios for card detect in mmc.
>
> This patch adds support to cd-gpios property.
>
> Signed-off-by: Walter Lozano 
> ---
>  tools/dtoc/dtb_platdata.py | 13 -
>  tools/dtoc/test_dtoc.py|  2 +-
>  2 files changed, 9 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH v11 00/18] RISC-V SiFive FU540 support SPL

2020-05-19 Thread Rick Chen
Hi Bin

> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Tuesday, May 19, 2020 4:44 PM
> To: Pragnesh Patel; Rick Jian-Zhi Chen(陳建志)
> Subject: Re: [PATCH v11 00/18] RISC-V SiFive FU540 support SPL
>
> Hi Rick,
>
> On Tue, May 19, 2020 at 3:04 PM Pragnesh Patel  
> wrote:
> >
> > This series add support for SPL to FU540. U-Boot SPL can boot from
> > L2 LIM (0x0800_) and jump to OpenSBI(FW_DYNAMIC firmware) and
> > U-Boot proper from MMC devices.
> >
> > This series depends on:
> > [1] https://patchwork.ozlabs.org/patch/1281853
> > [2] https://patchwork.ozlabs.org/patch/1281852
> >
> > All these together is available for testing here [3] [3]
> > https://github.com/pragnesh26992/u-boot/tree/spl
> >
> > How to test this patch:
> > 1) Go to OpenSBI-dir : make PLATFORM=generic FW_DYNAMIC=y
> > 2) export
> > OPENSBI= > n>
> > 3) Change to u-boot-dir
> > 4) make sifive_fu540_defconfig
> > 5) make all
> > 6) Format the SD card (make sure the disk has GPT, otherwise use gdisk
> > to switch)
> >
> > # sudo sgdisk --clear \
> > > --set-alignment=2 \
> > > --new=1:34:2081 --change-name=1:loader1 
> > --typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
> > > --new=2:2082:10273 --change-name=2:loader2 
> > --typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
> > > --new=3:10274: --change-name=3:rootfs 
> > --typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
> > > /dev/sda
> >
> > 7) sudo dd if=spl/u-boot-spl.bin of=/dev/sda seek=34
> > 8) sudo dd if=u-boot.itb of=/dev/sda seek=2082
> >
> > Changes in v11:
> > - Remove TPL related code and OF_PLATDATA from FU540
> >   DDR driver (drivers/ram/sifive/fu540_ddr.c)
> > - Update FU540 doc (doc/board/sifive/fu540.rst)
> >   Remove unnecessary print
>
> Could we get this v11 applied as soon as possible for v2020.07?

No problem, if everything is OK, I will applied ASAP.
But Jagan seem have some responses, please check about it.

>
> > This series depends on:
> > [1] https://patchwork.ozlabs.org/patch/1281853
> > [2] https://patchwork.ozlabs.org/patch/1281852
>
> Looks this series "riscv: Add Sipeed Maix support" was not applied neither ?

Yes, the reason is that the CI verification of v10 of this series
"riscv: Add Sipeed Maix support" still fail.
Please check the discussion of [v10,20/21] doc: riscv: Add
documentation for Sipeed Maix Bit

https://patchwork.ozlabs.org/project/uboot/patch/20200503024637.327733-21-sean...@gmail.com/

That is why I still not pull it yet.

Thanks,
Rick

>
> Regards,
> Bin


Re: [RFC 6/6] dtoc add test for cd-gpios

2020-05-19 Thread Simon Glass
On Wed, 13 May 2020 at 14:14, Walter Lozano  wrote:
>
> Add a test for dtoc taking into account the cd-gpios property.
>
> Signed-off-by: Walter Lozano 
> ---
>  tools/dtoc/dtoc_test_phandle_cd_gpios.dts | 42 +
>  tools/dtoc/test_dtoc.py   | 72 +++
>  2 files changed, 114 insertions(+)
>  create mode 100644 tools/dtoc/dtoc_test_phandle_cd_gpios.dts
>

Reviewed-by: Simon Glass 

A few more things - please check sandbox_spl, and also updates the docs.


- SImon


Re: [PATCH] ARM: add psci_arch_init() declaration for CONFIG_ARMV7_PSCI

2020-05-19 Thread Simon Glass
HI Masahiro,

On Tue, 19 May 2020 at 20:44, Masahiro Yamada
 wrote:
>
> arch/arm/include/asm/system.h declares psci_arch_init(), but it is
> surrounded by #ifdef CONFIG_ARMV8_PSCI.
>
> psci_arch_init() is called for CONFIG_ARMV7_PSCI too. Add the missing
> function declaration.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/arm/include/asm/system.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 1e3f574403..7a40b56acd 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -528,6 +528,7 @@ void mmu_page_table_flush(unsigned long start, unsigned 
> long stop);
>
>  #ifdef CONFIG_ARMV7_PSCI
>  void psci_arch_cpu_entry(void);
> +void psci_arch_init(void);

Could you add a function comment too?

>  u32 psci_version(void);
>  s32 psci_features(u32 function_id, u32 psci_fid);
>  s32 psci_cpu_off(void);
> --
> 2.25.1
>

Regards,
Simon


Re: [RFC 4/6] dtoc: update tests to match new platdata

2020-05-19 Thread Simon Glass
On Wed, 13 May 2020 at 14:14, Walter Lozano  wrote:
>
> After using a new approach to link nodes when OF_PLATDATA is enabled
> the test cases need to be update.
>
> This patch updates the tests based on this new implementation.
>
> Signed-off-by: Walter Lozano 
> ---
>  tools/dtoc/test_dtoc.py | 123 ++--
>  1 file changed, 81 insertions(+), 42 deletions(-)
>

Reviewed-by: Simon Glass 

BTW, setting .dev = NULL is not necessary. You could drop it  perhaps?


Re: [RFC 3/6] dtoc: extend dtoc to use struct driver_info when linking nodes

2020-05-19 Thread Simon Glass
Hi Walter,

On Wed, 13 May 2020 at 14:14, Walter Lozano  wrote:
>
> In the current implementation, when dtoc parses a dtb to generate a struct
> platdata it converts the information related to linked nodes as pointers
> to struct platdata of destination nodes. By doing this, it makes
> difficult to get pointer to udevices created based on these
> information.
>
> This patch extends dtoc to use struct driver_info when populating
> information about linked nodes, which makes it easier to later get
> the devices created. In this context, reimplement functions like
> clk_get_by_index_platdata() which made use of the previous approach.
>
> Signed-off-by: Walter Lozano 
> ---
>  drivers/clk/clk-uclass.c|  8 +++-
>  drivers/misc/irq-uclass.c   |  4 ++--
>  drivers/mmc/ftsdc010_mci.c  |  2 +-
>  drivers/mmc/rockchip_dw_mmc.c   |  2 +-
>  drivers/mmc/rockchip_sdhci.c|  2 +-
>  drivers/ram/rockchip/sdram_rk3399.c |  2 +-
>  drivers/spi/rk_spi.c|  2 +-
>  include/clk.h   |  2 +-
>  tools/dtoc/dtb_platdata.py  | 17 ++---
>  9 files changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> index 71878474eb..f24008fe00 100644
> --- a/drivers/clk/clk-uclass.c
> +++ b/drivers/clk/clk-uclass.c
> @@ -25,14 +25,12 @@ static inline const struct clk_ops *clk_dev_ops(struct 
> udevice *dev)
>
>  #if CONFIG_IS_ENABLED(OF_CONTROL)
>  # if CONFIG_IS_ENABLED(OF_PLATDATA)
> -int clk_get_by_index_platdata(struct udevice *dev, int index,
> - struct phandle_1_arg *cells, struct clk *clk)
> +int clk_get_by_driver_info(struct udevice *dev, struct phandle_1_arg *cells,
> +   struct clk *clk)
>  {
> int ret;
>
> -   if (index != 0)
> -   return -ENOSYS;

But it looks like you only support index 0?

> -   ret = uclass_get_device(UCLASS_CLK, 0, >dev);
> +   ret = device_get_by_driver_info((struct driver_info*) cells[0].node, 
> >dev);

Or do you mean [index] here instead of [0] ?

> if (ret)
> return ret;
> clk->id = cells[0].arg[0];
> diff --git a/drivers/misc/irq-uclass.c b/drivers/misc/irq-uclass.c
> index 61aa10e465..8eaebe6419 100644
> --- a/drivers/misc/irq-uclass.c
> +++ b/drivers/misc/irq-uclass.c
> @@ -63,14 +63,14 @@ int irq_read_and_clear(struct irq *irq)
>  }
>
>  #if CONFIG_IS_ENABLED(OF_PLATDATA)
> -int irq_get_by_index_platdata(struct udevice *dev, int index,
> +int irq_get_by_driver_info(struct udevice *dev,
>   struct phandle_1_arg *cells, struct irq *irq)
>  {
> int ret;
>
> if (index != 0)
> return -ENOSYS;
> -   ret = uclass_get_device(UCLASS_IRQ, 0, >dev);
> +   ret = device_get_by_driver_info(cells[0].node, >dev);
> if (ret)
> return ret;
> irq->id = cells[0].arg[0];
> diff --git a/drivers/mmc/ftsdc010_mci.c b/drivers/mmc/ftsdc010_mci.c
> index 9c15eb36d6..efa92d48be 100644
> --- a/drivers/mmc/ftsdc010_mci.c
> +++ b/drivers/mmc/ftsdc010_mci.c
> @@ -437,7 +437,7 @@ static int ftsdc010_mmc_probe(struct udevice *dev)
> chip->priv = dev;
> chip->dev_index = 1;
> memcpy(priv->minmax, dtplat->clock_freq_min_max, 
> sizeof(priv->minmax));
> -   ret = clk_get_by_index_platdata(dev, 0, dtplat->clocks, >clk);
> +   ret = clk_get_by_driver_info(dev, dtplat->clocks, >clk);
> if (ret < 0)
> return ret;
>  #endif
> diff --git a/drivers/mmc/rockchip_dw_mmc.c b/drivers/mmc/rockchip_dw_mmc.c
> index a0e1be8794..7b4479543c 100644
> --- a/drivers/mmc/rockchip_dw_mmc.c
> +++ b/drivers/mmc/rockchip_dw_mmc.c
> @@ -120,7 +120,7 @@ static int rockchip_dwmmc_probe(struct udevice *dev)
> priv->minmax[0] = 40;  /*  400 kHz */
> priv->minmax[1] = dtplat->max_frequency;
>
> -   ret = clk_get_by_index_platdata(dev, 0, dtplat->clocks, >clk);
> +   ret = clk_get_by_driver_info(dev, dtplat->clocks, >clk);
> if (ret < 0)
> return ret;
>  #else
> diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
> index b440996b26..b073f1a08d 100644
> --- a/drivers/mmc/rockchip_sdhci.c
> +++ b/drivers/mmc/rockchip_sdhci.c
> @@ -46,7 +46,7 @@ static int arasan_sdhci_probe(struct udevice *dev)
> host->name = dev->name;
> host->ioaddr = map_sysmem(dtplat->reg[0], dtplat->reg[1]);
> max_frequency = dtplat->max_frequency;
> -   ret = clk_get_by_index_platdata(dev, 0, dtplat->clocks, );
> +   ret = clk_get_by_driver_info(dev, dtplat->clocks, );
>  #else
> max_frequency = dev_read_u32_default(dev, "max-frequency", 0);
> ret = clk_get_by_index(dev, 0, );
> diff --git a/drivers/ram/rockchip/sdram_rk3399.c 
> b/drivers/ram/rockchip/sdram_rk3399.c
> index d69ef01d08..87ec25f893 100644
> --- a/drivers/ram/rockchip/sdram_rk3399.c
> +++ 

Re: [RFC 2/6] core: extend struct driver_info to point to device

2020-05-19 Thread Simon Glass
Hi Walter,

On Wed, 13 May 2020 at 14:14, Walter Lozano  wrote:
>
> Currently when creating an U_BOOT_DEVICE entry a struct driver_info
> is declared, which contains the data needed to instantiate the device.
> However, the actual device is created at runtime and there is no proper
> way to get the device based on its struct driver_info.
>
> This patch extends struct driver_info adding a pointer to udevice which
> is populated during the bind process, allowing to generate a set of
> functions to get the device based on its struct driver_info.
>
> Signed-off-by: Walter Lozano 
> ---
>  drivers/core/device.c| 25 +++--
>  drivers/core/root.c  |  6 +-
>  include/dm/device-internal.h |  2 +-
>  include/dm/device.h  | 13 +
>  include/dm/platdata.h|  6 ++
>  5 files changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 0157bb1fe0..2476f170a5 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -246,10 +246,11 @@ int device_bind_ofnode(struct udevice *parent, const 
> struct driver *drv,
>  }
>
>  int device_bind_by_name(struct udevice *parent, bool pre_reloc_only,
> -   const struct driver_info *info, struct udevice **devp)
> +   struct driver_info *info, struct udevice **devp)
>  {
> struct driver *drv;
> uint platdata_size = 0;
> +   int ret = 0;
>
> drv = lists_driver_lookup_name(info->name);
> if (!drv)
> @@ -260,9 +261,19 @@ int device_bind_by_name(struct udevice *parent, bool 
> pre_reloc_only,
>  #if CONFIG_IS_ENABLED(OF_PLATDATA)
> platdata_size = info->platdata_size;
>  #endif
> -   return device_bind_common(parent, drv, info->name,
> +   ret = device_bind_common(parent, drv, info->name,
> (void *)info->platdata, 0, ofnode_null(), 
> platdata_size,
> devp);
> +

drop blank line

> +   if (ret)
> +   return ret;
> +
> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> +   info->dev = *devp;
> +#endif
> +
> +   return ret;
> +

and here

>  }
>
>  static void *alloc_priv(int size, uint flags)
> @@ -727,6 +738,16 @@ int device_get_global_by_ofnode(ofnode ofnode, struct 
> udevice **devp)
> return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp);
>  }
>
> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> +int device_get_by_driver_info(struct driver_info * info, struct udevice 
> **devp)
> +{
> +   struct udevice *dev;
> +
> +   dev = info->dev;

blank line before return:-)

> +   return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp);
> +}
> +#endif
> +
>  int device_find_first_child(const struct udevice *parent, struct udevice 
> **devp)
>  {
> if (list_empty(>child_head)) {
> diff --git a/drivers/core/root.c b/drivers/core/root.c
> index 14df16c280..8f47a6b356 100644
> --- a/drivers/core/root.c
> +++ b/drivers/core/root.c
> @@ -25,7 +25,7 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> -static const struct driver_info root_info = {
> +static struct driver_info root_info = {
> .name   = "root_driver",
>  };
>
> @@ -346,6 +346,10 @@ int dm_init_and_scan(bool pre_reloc_only)
>  {
> int ret;
>
> +#if CONFIG_IS_ENABLED(OF_PLATDATA)

This one can use if() I think

> +   populate_phandle_data();
> +#endif
> +
> ret = dm_init(IS_ENABLED(CONFIG_OF_LIVE));
> if (ret) {
> debug("dm_init() failed: %d\n", ret);
> diff --git a/include/dm/device-internal.h b/include/dm/device-internal.h
> index 294d6c1810..5145fb4e14 100644
> --- a/include/dm/device-internal.h
> +++ b/include/dm/device-internal.h
> @@ -81,7 +81,7 @@ int device_bind_with_driver_data(struct udevice *parent,
>   * @return 0 if OK, -ve on error
>   */
>  int device_bind_by_name(struct udevice *parent, bool pre_reloc_only,
> -   const struct driver_info *info, struct udevice 
> **devp);
> +   struct driver_info *info, struct udevice **devp);

That change should really be a separate patch I think.

>
>  /**
>   * device_ofdata_to_platdata() - Read platform data for a device
> diff --git a/include/dm/device.h b/include/dm/device.h
> index d5b3e732c3..590c1f99ce 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -537,6 +537,19 @@ int device_find_global_by_ofnode(ofnode node, struct 
> udevice **devp);
>   */
>  int device_get_global_by_ofnode(ofnode node, struct udevice **devp);
>
> +/**
> + * device_get_by_driver_info() - Get a device based on driver_info
> + *
> + * Locates a device by its struct driver_info.
> + *
> + * The device is probed to activate it ready for use.
> + *
> + * @info: Struct driver_info
> + * @devp: Returns pointer to device if found, otherwise this is set to NULL
> + * @return 0 if OK, -ve on error
> + */
> +int device_get_by_driver_info(struct driver_info * info, struct udevice 
> **devp);
> +
>  /**
>   * 

Re: [PATCH 05/10] x86: Convert from ACCESS_ONCE to READ/WRITE_ONCE

2020-05-19 Thread Simon Glass
On Thu, 14 May 2020 at 06:30, Tom Rini  wrote:
>
> In order to update our  to a newer version that no
> longer provides ACCESS_ONCE() but only READ_ONCE()/WRITE_ONCE() we need
> to convert arch/x86/include/asm/atomic.h to the other macros.
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Signed-off-by: Tom Rini 
> ---
>  arch/x86/include/asm/atomic.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [RFC 1/6] dtoc: add support to scan drivers

2020-05-19 Thread Simon Glass
Hi Walter,

On Wed, 13 May 2020 at 14:13, Walter Lozano  wrote:
>
> Currently dtoc scans dtbs to convert them to struct platdata and
> to generate U_BOOT_DEVICE entries. These entries need to be filled
> with the driver name, but at this moment the information used is the
> compatible name present in the dtb. This causes that only nodes with
> a compatible name that matches a driver name generate a working
> entry.
>
> In order to improve this behaviour, this patch adds to dtoc the
> capability of scan drivers source code to generate a list of valid driver
> names. This allows to rise a warning in the case that an U_BOOT_DEVICE
> entry will try to use a name not valid.
>
> Additionally, in order to add more flexibility to the solution, adds the
> U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an
> easy way to declare driver name aliases. Thanks to this, dtoc can look
> for the driver name based on its alias when it populates the U_BOOT_DEVICE 
> entry.
>
> Signed-off-by: Walter Lozano 
> ---
>  include/dm/device.h|  6 +
>  tools/dtoc/dtb_platdata.py | 53 +++---
>  2 files changed, 55 insertions(+), 4 deletions(-)
>
> diff --git a/include/dm/device.h b/include/dm/device.h
> index 975eec5d0e..d5b3e732c3 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -282,6 +282,12 @@ struct driver {
>  #define DM_GET_DRIVER(__name)  \
> ll_entry_get(struct driver, __name, driver)
>
> +/* Declare a macro to state a alias for a driver name. This macro will

/*
 * Declare ...

> + * produce no code but its information will be parsed by tools like
> + * dtoc
> + */
> +#define U_BOOT_DRIVER_ALIAS(__name, __alias)
> +
>  /**
>   * dev_get_platdata() - Get the platform data for a device
>   *
> diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
> index ecfe0624d1..3f899a8bac 100644
> --- a/tools/dtoc/dtb_platdata.py
> +++ b/tools/dtoc/dtb_platdata.py
> @@ -14,6 +14,8 @@ static data.
>  import collections
>  import copy
>  import sys
> +import os
> +import re

please keep sorted

>
>  from dtoc import fdt
>  from dtoc import fdt_util
> @@ -149,6 +151,20 @@ class DtbPlatdata(object):
>  self._outfile = None
>  self._lines = []
>  self._aliases = {}
> +self._drivers = []
> +self._driver_aliases = {}

Please update comment above for what these new things are for.

> +
> +def get_normalized_compat_name(self, node):

Needs function comment (also for those below).

> +compat_c, aliases_c = get_compat_name(node)
> +if compat_c not in self._drivers:
> +try: # pragma: no cover

Instead of an exception can you use .get() and check for None?

> +compat_c_old = compat_c
> +compat_c = self._driver_aliases[compat_c]
> +aliases_c = [compat_c_old] + aliases
> +except:
> +print('WARNING: the driver %s was not found in the driver 
> list' % (compat_c))
> +
> +return compat_c, aliases_c
>
>  def setup_output(self, fname):
>  """Set up the output destination
> @@ -243,6 +259,34 @@ class DtbPlatdata(object):
>  return PhandleInfo(max_args, args)
>  return None
>
> +def scan_driver(self, fn):
> +f = open(fn)

Can you avoid single-char var names? Also how about either using
tools.ReadFile() or:

with open(fname) as fd:
...rest of function

> +
> +b = f.read()
> +
> +drivers = re.findall('U_BOOT_DRIVER\((.*)\)', b)
> +
> +for d in drivers:
> +self._drivers.append(d)
> +
> +driver_aliases = 
> re.findall('U_BOOT_DRIVER_ALIAS\(\s*(\w+)\s*,\s*(\w+)\s*\)', b)

Can you add a comment before this with an example of the line you are
parsing? It helps make sense of the regex.

> +
> +for a in driver_aliases: # pragma: no cover
> +try:
> +self._driver_aliases[a[1]] = a[0]
> +except:
> +pass

Again please avoid exceptions.

> +
> +def scan_drivers(self):
> +"""Scan the driver folders to build a list of driver names and 
> possible
> +aliases
> +"""
> +for (dirpath, dirnames, filenames) in os.walk('./'):
> +for fn in filenames:
> +if not fn.endswith('.c'):
> +continue
> +self.scan_driver(dirpath + '/' + fn)
> +
>  def scan_dtb(self):
>  """Scan the device tree to obtain a tree of nodes and properties
>
> @@ -353,7 +397,7 @@ class DtbPlatdata(object):
>  """
>  structs = {}
>  for node in self._valid_nodes:
> -node_name, _ = get_compat_name(node)
> +node_name, _ = self.get_normalized_compat_name(node)
>  fields = {}

I wonder how long this scan takes? Should we cache the results somewhere?

>
>  # Get a list of all the valid 

Re: [RFC 0/6] improve OF_PLATDATA support

2020-05-19 Thread Simon Glass
Hi Walter,

On Wed, 13 May 2020 at 14:13, Walter Lozano  wrote:
>
> When using OF_PLATDATA dtbs are converted to C structs in order to save
> space as we can remove both dtbs and libraries from TPL/SPL binaries.
>
> This patchset tries to improve its support by overcoming some limitations
> in the current implementation
>
> First, the support for scan and check for valid driver/aliases is added
> in order to generate U_BOOT_DEVICE entries with valid driver names.
>
> Secondly, the way information about linked noded (phandle) is generated
> in C structs is improved in order to make it easier to get a device
> associated to its data.
>
> Lastly the the suport for the property cd-gpios is added, which is used to
> configure the card detection gpio on MMC is added.
>
> This implementation is based in discussion in [1] and [2]
>
> [1] https://patchwork.ozlabs.org/patch/1249198/
> [2] https://patchwork.ozlabs.org/project/uboot/list/?series=167495=*
>
> Walter Lozano (6):
>   dtoc: add support to scan drivers
>   core: extend struct driver_info to point to device
>   dtoc: extend dtoc to use struct driver_info when linking nodes
>   dtoc: update tests to match new platdata
>   dtoc: update dtb_platdata to support cd-gpios
>   dtoc add test for cd-gpios
>
>  drivers/clk/clk-uclass.c  |   8 +-
>  drivers/core/device.c |  25 ++-
>  drivers/core/root.c   |   6 +-
>  drivers/misc/irq-uclass.c |   4 +-
>  drivers/mmc/ftsdc010_mci.c|   2 +-
>  drivers/mmc/rockchip_dw_mmc.c |   2 +-
>  drivers/mmc/rockchip_sdhci.c  |   2 +-
>  drivers/ram/rockchip/sdram_rk3399.c   |   2 +-
>  drivers/spi/rk_spi.c  |   2 +-
>  include/clk.h |   2 +-
>  include/dm/device-internal.h  |   2 +-
>  include/dm/device.h   |  19 +++
>  include/dm/platdata.h |   6 +
>  tools/dtoc/dtb_platdata.py|  83 +++--
>  tools/dtoc/dtoc_test_phandle_cd_gpios.dts |  42 +
>  tools/dtoc/test_dtoc.py   | 197 +-
>  16 files changed, 332 insertions(+), 72 deletions(-)
>  create mode 100644 tools/dtoc/dtoc_test_phandle_cd_gpios.dts
>
> --
> 2.20.1
>

This looks really nice. I think you can take off the RFC. Also run
through patman/checkpatch.

Regards,
Simon


Re: [PATCH v5 3/3] gpio: search for gpio label if gpio is not found through bank name

2020-05-19 Thread Simon Glass
Hi Heiko,

On Fri, 15 May 2020 at 08:02, Heiko Schocher  wrote:
>
> dm_gpio_lookup_name() searches for a gpio through
> the bank name. But we have also gpio labels, and it
> makes sense to search for a gpio also in the labels
> we have defined, if no gpio is found through the
> bank name definition.
>
> This is useful for example if you have a wp pin on
> different gpios on different board versions.
>
> If dm_gpio_lookup_name() searches also for the gpio labels,
> you can give the gpio an unique label name and search
> for this label, and do not need to differ between
> board revisions.
>
> Signed-off-by: Heiko Schocher 
> ---
>
> Example on the aristainetos board:
>
> => gpio clear wp_spi_nor.gpio-hog
> gpio: pin wp_spi_nor.gpio-hog (gpio 47) value is 0
> =>
>
> before this patch, you need to know where your
> pin is:
>
> => gpio clear GPIO2_15
> gpio: pin GPIO2_15 (gpio 47) value is 0
> =>
>
> travis build:
>
> Changes in v5: None
> Changes in v4:
> - rebased to current master ac14bc4169
>
> Changes in v3:
> - add comment from Simon Glass
>   make this new function configurable through Kconfig
>   option DM_GPIO_LOOKUP_LABEL
>
> Changes in v2:
> - add comment from Simon Glass
>   move code into seperate function dm_gpio_lookup_label()
>   add test if dm_gpio_lookup_label() works
>
>  drivers/gpio/Kconfig   | 22 ++
>  drivers/gpio/gpio-uclass.c | 47 ++
>  test/dm/gpio.c |  7 ++
>  3 files changed, 76 insertions(+)

Reviewed-by: Simon Glass 

Some optional thoughts below

>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 2081520f42..4a635b905c 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -46,6 +46,28 @@ config GPIO_HOG
>   is a mechanism providing automatic GPIO request and config-
>   uration as part of the gpio-controller's driver probe function.
>
> +config DM_GPIO_LOOKUP_LABEL
> +   bool "Enable searching for gpio labelnames"
> +   depends on DM_GPIO
> +   default y
> +   help
> + This option enables searching for gpio names in
> + the defined gpio labels, if the search for the
> + gpio bank name failed. This makes sense if you use
> + different gpios on different hardware versions
> + for the same functionality in board code.
> +
> +config SPL_DM_GPIO_LOOKUP_LABEL
> +   bool "Enable searching for gpio labelnames"
> +   depends on DM_GPIO && SPL_DM && SPL_GPIO_SUPPORT

Perhaps the first term could be DM_GPIO_LOOKUP_LABEL?

> +   default n

Not needed

> +   help
> + This option enables searching for gpio names in
> + the defined gpio labels, if the search for the
> + gpio bank name failed. This makes sense if you use
> + different gpios on different hardware versions
> + for the same functionality in board code.
> +
>  config ALTERA_PIO
> bool "Altera PIO driver"
> depends on DM_GPIO
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index d241263970..317b486982 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -67,6 +67,46 @@ static int gpio_to_device(unsigned int gpio, struct 
> gpio_desc *desc)
> return ret ? ret : -ENOENT;
>  }
>
> +#if CONFIG_IS_ENABLED(DM_GPIO_LOOKUP_LABEL)
> +/**
> + * dm_gpio_lookup_label() - look for name in gpio device
> + *
> + * search in uc_priv, if there is a gpio with labelname same
> + * as name.
> + *
> + * @name:  name which is searched
> + * @uc_priv:   gpio_dev_priv pointer.
> + * @offset:gpio offset within the device
> + * @return:0 if found, -ENOENT if not.
> + */
> +static int

I prefer to have the type on the same line as the function

> +dm_gpio_lookup_label(const char *name, struct gpio_dev_priv *uc_priv,
> +ulong *offset)
> +{
> +   int len;
> +   int i;
> +
> +   *offset = -1;
> +   len = strlen(name);
> +   for (i = 0; i < uc_priv->gpio_count; i++) {
> +   if (!uc_priv->name[i])
> +   continue;
> +   if (!strncmp(name, uc_priv->name[i], len)) {
> +   *offset = i;
> +   return 0;
> +   }
> +   }
> +   return -ENOENT;
> +}
> +#else
> +static int
> +dm_gpio_lookup_label(const char *name, struct gpio_dev_priv *uc_priv,
> +ulong *offset)
> +{
> +   return -ENOENT;
> +}
> +#endif
> +
>  int dm_gpio_lookup_name(const char *name, struct gpio_desc *desc)
>  {
> struct gpio_dev_priv *uc_priv = NULL;
> @@ -95,6 +135,13 @@ int dm_gpio_lookup_name(const char *name, struct 
> gpio_desc *desc)
> if (!strict_strtoul(name + len, 10, ))
> break;
> }
> +
> +   /*
> +* if we did not found a gpio through its bank
> +* name, we search for a valid gpio label.
> +   

Re: [PATCH v5 1/3] gpio-uclass.c: save the GPIOD flags also in the gpio descriptor

2020-05-19 Thread Simon Glass
On Fri, 15 May 2020 at 08:01, Heiko Schocher  wrote:
>
> save the GPIOD_ flags also in the gpio descriptor.
>
> Signed-off-by: Heiko Schocher 
>
>
> ---
>
> Changes in v5:
> - add comment from patrick, update the descriptor flags
>   in _dm_gpio_set_dir_flags() if setting direction was OK.
>
> Changes in v4:
> - new in version 4
>
> Changes in v3: None
> Changes in v2: None
>
>  drivers/gpio/gpio-uclass.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

Would be good mention 'why' in patches like this.

Reviewed-by: Simon Glass 


Re: [PATCH v3 2/7] uart: pl011: Add proper DM clock support

2020-05-19 Thread Simon Glass
Hi André,

On Tue, 12 May 2020 at 08:27, André Przywara  wrote:
>
> On 28/04/2020 18:57, Simon Glass wrote:
>
> Hi,
>
> sorry for the delay, found this, slightly mouldy already, in my draft
> folder.
>
> First, thanks for the review! I saw the Tom merged this already, but
> wanted to come back to the DT hacks:
>
> > Hi Andre,
> >
> > On Mon, 27 Apr 2020 at 12:18, Andre Przywara  wrote:
> >>
> >> Even though the PL011 UART driver claims to be DM compliant, it does not
> >> really a good job with parsing DT nodes. U-Boot seems to adhere to a
> >> non-standard binding, either requiring to have a "skip-init" property in
> >> the node, or to have an extra "clock" property holding the base
> >> *frequency* value for the baud rate generator.
> >> DTs in the U-Boot tree seem to have been hacked to match this
> >> requirement.
> >
> > One problem is that we want a 'debug UART' to work before the clock
> > driver is running, so we want to do the *minimum possible* amount of
> > init to get the UART running. So we don't want to start up driver
> > model, clock drivers, etc.
>
> I understand this very well - having an UART up and running as early as
> possible is crucial for debugging.
>
> > I think we should have useful helpers like the 'clock' property to
> > avoid lots of parsing very early in U-Boot. Of course such things are
> > hard for kernel people to understand / agree to but that doesn't make
> > them wrong.
>
> I agree, but I don't think we should mess around with the DT for this
> purpose. This is basically a U-Boot requirement or debug feature, not a
> machine property. And deviating from the official DT binding is not a
> good idea.
>
> I think for those U-Boot specific debug features we can just have CONFIG
> options - for instance we already have CONFIG_PL011_CLOCK. Also I
> strongly believe that skip-init does not belong into the DT. It's a
> *U-Boot* decision to not *re*-init the UART, not a machine property.
> There are PL011 compatible UARTs which should *not* be initialised
> (SBSA-UART), but both TX1 and RPi don't have those, but instead real PL011s.
> So if we desperately wanted this in the DT, we could actually use
> compatible = "arm,sbsa-uart", then we don't need any clock at all.

Yes of course these are U-Boot decisions in some sense. But they are
also hardware-related. There is nothing wrong with having a fixed
clock as a default, for simple software to use.

We have a persistent problem here because of this 'linux' idea that we
cannot have config in the DT. It is generally the only thing available
to U-Boot. It is certainly the only thing available for runtime
config.

Why not put a 'u-boot' prefix on it and be done?

If we could just get over this hangup, it would be so great for U-Boot
:-) It doesn't have the ability to rely on user space for policy.

>
> But I was more thinking about turning skip-init into a config symbol and
> defining this for TX1 and RPi. We do already something similar for the
> RPi4 in Trusted Firmware [1]. This would allow us to remove the
> skip-init property from the u-boot.dtsi, and would help with booting
> with the DT from the SD card instead (for which the GPU firmware puts
> the pointer to into the beginning of memory [2]).

You mean we have to build U-Boot differently depending on what it is
booting from? I wonder if we could pass this information through to
U-Boot instead.

>
> I have a patch for that already, will send it soonish.

Regards,
Simon


Re: U-CLASS SPI Bus and Devices

2020-05-19 Thread Simon Glass
Hi Rudolf,

On Tue, 12 May 2020 at 18:02, Rudolf J Streif  wrote:
>
> Hi Simon,
>
> Thanks for your response.
>
> On 5/7/20 6:36 PM, Simon Glass wrote:
> > Hi Rudolf,
> >
> > On Wed, 18 Mar 2020 at 05:25, Rudolf J Streif  
> > wrote:
> >> I ran into an issue today with a U-CLASS SPI NOR flash device on a NXP
> >> FlexSPI controller. U-Boot started correctly from the flash device but
> >> using 'sf probe 0:0' would always return 'Invalid bus 0 (err=-19)'. This
> >> error message is emitted by spi_get_bus_and_cs() in
> >> drivers/spi/spi-uclass.c. I traced the issue to
> >> uclass_get_device_by_seq() in drivers/core/uclass.c.
> >>
> >> The function first searches the device list for a device that already
> >> claimed the sequence number (dev->seq). If not found it would look if a
> >> device requested that sequence number (dev->seq_req). That would always
> >> fail for my device. The bus had not been probed yet and hence dev->seq
> >> was -1 and the device also had dev->req_seq set to -1.
> >>
> >> The board is using a device tree hence it would only make sense to set
> >> the requested sequence number via the device tree. However, there is no
> >> such thing and even if there was it might not be specified.
> >>
> >> Consequently, the device was never probed although the driver was
> >> correctly set up via device tree.
> >>
> >> I worked around it by simply setting dev->req_seq of the first device
> >> that had it set to -1 to the sequence number the search function was
> >> looking for (see patch below). It solved my problem but I don't know if
> >> that is the right way of addressing it. I could not find any other
> >> solution for this particular problem anywhere.
> >>
> >> Rudi
> > You can put the SPI flash in the device tree with an alias pointing to
> > it.. That is the intended way with driver model.
>
> The board I am using the the FSL/NXP LX2160A-RDB. The dts
> arch/arm/dts/fsl-lx2160a-rdb.dts defines:
>
>  / {
> model = "NXP Layerscape LX2160ARDB Board";
> compatible = "fsl,lx2160ardb", "fsl,lx2160a";
>
> aliases {
> spi0 = 
> };
> };
>
> I am I missing something?

That's SPI. I mean actually SPI flash, which would be a subnode of that,

Regards,
SImon


Re: [PATCH v5 2/3] sandbox, test: add test for GPIO_HOG function

2020-05-19 Thread Simon Glass
Hi Heiko,

On Fri, 15 May 2020 at 08:02, Heiko Schocher  wrote:
>
> currently gpio hog function is not tested with "ut dm gpio"
> so add some basic tests for gpio hog functionality.
>
> For this enable GPIO_HOG in sandbox_defconfig, add
> in DTS some gpio hog entries, and add testcase in
> "ut dm gpio" command.
>
> Signed-off-by: Heiko Schocher 
>
> ---
>
> Changes in v5: None
> Changes in v4:
> - rebased to current master ac14bc4169
>
> Changes in v3: None
> Changes in v2:
> - add basic gpio hog test functions
>
>  arch/sandbox/dts/test.dts  | 20 
>  configs/sandbox64_defconfig|  1 +
>  configs/sandbox_defconfig  |  1 +
>  configs/sandbox_flattree_defconfig |  1 +
>  configs/sandbox_spl_defconfig  |  1 +
>  test/dm/gpio.c | 23 +++
>  6 files changed, 47 insertions(+)
>

Reviewed-by: Simon Glass 

It is OK to just enable on sandbox if you like, since we don't
normally run the bulk of the tests on the others.


[PATCH] ARM: add psci_arch_init() declaration for CONFIG_ARMV7_PSCI

2020-05-19 Thread Masahiro Yamada
arch/arm/include/asm/system.h declares psci_arch_init(), but it is
surrounded by #ifdef CONFIG_ARMV8_PSCI.

psci_arch_init() is called for CONFIG_ARMV7_PSCI too. Add the missing
function declaration.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/include/asm/system.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 1e3f574403..7a40b56acd 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -528,6 +528,7 @@ void mmu_page_table_flush(unsigned long start, unsigned 
long stop);
 
 #ifdef CONFIG_ARMV7_PSCI
 void psci_arch_cpu_entry(void);
+void psci_arch_init(void);
 u32 psci_version(void);
 s32 psci_features(u32 function_id, u32 psci_fid);
 s32 psci_cpu_off(void);
-- 
2.25.1



RE: [PATCH] cpu: imx8: use intended cpu-thermal device when getting temp value

2020-05-19 Thread Peng Fan
> Subject: [PATCH] cpu: imx8: use intended cpu-thermal device when getting
> temp value
> 
> This fixes getting DT alert and critical pdata values in imx_scu_thermal 
> driver.
> On i.MX8QXP using not initialized alert pdata value resulted in boot hang and
> endless loop outputting:
> CPU Temperature (47200C) has beyond alert (0C), close to critical (0C)
> waiting...
> 
> While at it, preset CPU type values once to avoid multiple calls of
> device_is_compatible() for same property.
> 
> Fixes: 3ee6ea443eb4 ("cpu: imx_cpu: Print the CPU temperature for iMX8QM
> A72")
> Signed-off-by: Anatolij Gustschin 
> ---
> This one supersedes the older patch here:
> 
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchw
> ork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2F20200516203420.24409-2-a
> gust%40denx.dedata=02%7C01%7Cpeng.fan%40nxp.com%7C3a05de6
> b676d4479832a08d7fc4ccc4d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> 0%7C0%7C637255279084654887sdata=W7kv5XqeSrcxcOHNgE0TgcR8
> POPyt3VR4EsWszlFXLI%3Dreserved=0
> 
>  drivers/cpu/imx8_cpu.c | 50 +-
>  1 file changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/cpu/imx8_cpu.c b/drivers/cpu/imx8_cpu.c index
> 896e1ac776..adc4919d9e 100644
> --- a/drivers/cpu/imx8_cpu.c
> +++ b/drivers/cpu/imx8_cpu.c
> @@ -18,6 +18,7 @@ struct cpu_imx_platdata {
>   const char *name;
>   const char *rev;
>   const char *type;
> + u32 cpu_rsrc;
>   u32 cpurev;
>   u32 freq_mhz;
>   u32 mpidr;
> @@ -50,16 +51,23 @@ const char *get_imx8_rev(u32 rev)
>   }
>  }
> 
> -const char *get_core_name(struct udevice *dev)
> +static void set_core_data(struct udevice *dev)
>  {
> - if (device_is_compatible(dev, "arm,cortex-a35"))
> - return "A35";
> - else if (device_is_compatible(dev, "arm,cortex-a53"))
> - return "A53";
> - else if (device_is_compatible(dev, "arm,cortex-a72"))
> - return "A72";
> - else
> - return "?";
> + struct cpu_imx_platdata *plat = dev_get_platdata(dev);
> +
> + if (device_is_compatible(dev, "arm,cortex-a35")) {
> + plat->cpu_rsrc = SC_R_A35;
> + plat->name = "A35";
> + } else if (device_is_compatible(dev, "arm,cortex-a53")) {
> + plat->cpu_rsrc = SC_R_A53;
> + plat->name = "A53";
> + } else if (device_is_compatible(dev, "arm,cortex-a72")) {
> + plat->cpu_rsrc = SC_R_A72;
> + plat->name = "A72";
> + } else {
> + plat->cpu_rsrc = SC_R_A53;
> + plat->name = "?";
> + }
>  }
> 
>  #if IS_ENABLED(CONFIG_IMX_SCU_THERMAL)
> @@ -67,12 +75,12 @@ static int cpu_imx_get_temp(struct cpu_imx_platdata
> *plat)  {
>   struct udevice *thermal_dev;
>   int cpu_tmp, ret;
> + int idx = 1; /* use "cpu-thermal0" device */
> 
> - if (!strcmp(plat->name, "A72"))
> - ret = uclass_get_device(UCLASS_THERMAL, 1, _dev);
> - else
> - ret = uclass_get_device(UCLASS_THERMAL, 0, _dev);
> + if (plat->cpu_rsrc == SC_R_A72)
> + idx = 2; /* use "cpu-thermal1" device */
> 
> + ret = uclass_get_device(UCLASS_THERMAL, idx, _dev);
>   if (!ret) {
>   ret = thermal_get_temp(thermal_dev, _tmp);
>   if (ret)
> @@ -180,19 +188,11 @@ static const struct udevice_id cpu_imx8_ids[] = {
> 
>  static ulong imx8_get_cpu_rate(struct udevice *dev)  {
> + struct cpu_imx_platdata *plat = dev_get_platdata(dev);
>   ulong rate;
> - int ret, type;
> -
> - if (device_is_compatible(dev, "arm,cortex-a35"))
> - type = SC_R_A35;
> - else if (device_is_compatible(dev, "arm,cortex-a53"))
> - type = SC_R_A53;
> - else if (device_is_compatible(dev, "arm,cortex-a72"))
> - type = SC_R_A72;
> - else
> - return 0;
> + int ret;
> 
> - ret = sc_pm_get_clock_rate(-1, type, SC_PM_CLK_CPU,
> + ret = sc_pm_get_clock_rate(-1, plat->cpu_rsrc, SC_PM_CLK_CPU,
>  (sc_pm_clock_rate_t *));
>   if (ret) {
>   printf("Could not read CPU frequency: %d\n", ret); @@ -207,9
> +207,9 @@ static int imx8_cpu_probe(struct udevice *dev)
>   struct cpu_imx_platdata *plat = dev_get_platdata(dev);
>   u32 cpurev;
> 
> + set_core_data(dev);
>   cpurev = get_cpu_rev();
>   plat->cpurev = cpurev;
> - plat->name = get_core_name(dev);
>   plat->rev = get_imx8_rev(cpurev & 0xFFF);
>   plat->type = get_imx8_type((cpurev & 0xFF000) >> 12);
>   plat->freq_mhz = imx8_get_cpu_rate(dev) / 100;
> --
> 2.17.1

Reviewed-by: Peng Fan 


Re: [PATCH v1 1/3] board: ns3: add optee based bnxt fw load driver

2020-05-19 Thread Thomas Fitzsimmons
Hi Rayagonda and Vikas,

Rayagonda Kokatanur  writes:

> From: Vikas Gupta 
>
> Add optee based bnxt fw load driver.

What is "bnxt"?  Maybe you could add a comment explaining what it is, or
at least expanding it if it's an acronym?

Thanks,
Thomas


Re: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc

2020-05-19 Thread Thomas Fitzsimmons
Rayagonda Kokatanur  writes:

> On Tue, May 19, 2020 at 11:01 PM Tom Rini  wrote:
>>
>> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur wrote:
>> > Hi Tom,
>> >
>> >
>> > On Tue, May 19, 2020 at 12:46 AM Tom Rini  wrote:
>> > >
>> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur wrote:
>> > >
>> > > > This is the second patch set series prepared on top of the
>> > > > first patch set ("add initial support for broadcom NS3 soc").
>> > > >
>> > > > This patch set will add following,
>> > > > -dt nodes and defconfig options for basic device like pinctrl,
>> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
>> > > > -start wdt service
>> > > > -Enable GPT commands
>> > > > -Enable EXT4 and FAT fs support
>> > >
>> > > All of the dts changes not in a -u-boot.dtsi file either come from
>> > > mainline Linux or at least linux-next and have had some level upstream
>> > > review, right?  Thanks!
>> >
>> > Yes. All the DTS changes are merged in the Linux and are available at
>> > arch/arm64/boot/dts/broadcom/stingray/
>>
>> Great.  Please reference the release you're taking these from as that
>> will make future resyncs easier.  Thanks!
>
> It's Linux v5.6.

What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
looked at the mainline Linux device trees and I couldn't easily see the
correspondence.  Will the renaming complicate synchronization?

Thomas


Re: [PATCH v1 2/3] board: ns3: add FIT image its file

2020-05-19 Thread Thomas Fitzsimmons
Hi Rayagonda and Pramod,

Rayagonda Kokatanur  writes:

> From: Pramod Kumar 
>
> Add FIT image its file.

The .its file and dev keys seem generic.  Are you intending to add to
the .its file subsequently, e.g., to demonstrate FIT usage unique to the
NS3?

Thomas


Re: patman: ImportError

2020-05-19 Thread Simon Glass
Hi Stefan,

On Sun, 17 May 2020 at 07:54, Stefan Bosch  wrote:
>
> Hi Simon,
>
> Am 17.05.20 um 01:03 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Sat, 16 May 2020 at 05:27, Stefan Bosch  wrote:
> >>
> >> Hello,
> >>
> >> recently, I updated my local repository (U-Boot master). Last commit is
> >> c693f212c5b0433b3a49a89d87cbff28bf78eb87 now. Previously it has been
> >> 4df3578119b043d76b86b50077b06898fc2a4f62 (Date:   Wed Dec 18 18:25:42
> >> 2019 +0100).
> >>
> >> Now I get an "ImportError" if I call patman:
> >>
> >> u-boot_master$ ./tools/patman/patman --help
> >> Traceback (most recent call last):
> >> File "./tools/patman/patman", line 21, in 
> >>   from patman import checkpatch
> >> File
> >> "/home/stefan/u-boot_master/tools/patman/../patman/checkpatch.py", line
> >> 10, in 
> >>   from patman import command
> >> File "/home/stefan/u-boot_master/tools/patman/../patman/command.py",
> >> line 8, in 
> >>   from patman import tools
> >> File "/home/stefan/u-boot_master/tools/patman/../patman/tools.py",
> >> line 13, in 
> >>   from patman import command
> >> ImportError: cannot import name 'command'
> >>
> >> Cause of this 'ImportError' is probably that "from patman import
> >> command" has already been done before in checkpatch.py (circular
> >> dependency). I think the error has to do with your your commit
> >> bf776679a73f3b9eae37aabd2be5754483039cb2 (patman: Move to absolute 
> >> imports).
> >>
> >> My Python version is 3.4.3.
> >
> > The circular dependency has been there for some time, but perhaps in
> > Python 2, not Python 3. My Python is 3.6.9 or 3.7.7.
> >
> > I sent a patch to break the circular dependency. Can you please try it
> > and see if it helps?
> >
> > Regards,
> > Simon
> >
>
> Thanks for your quick reply. I tried your patch, the good news is that
> the ImportError for 'command' has been gone. The bad news is that the
> same occurs for 'checkpatch' now:
>
> $ ./tools/patman/patman --help
> Traceback (most recent call last):
>File "./tools/patman/patman", line 21, in 
>  from patman import checkpatch
>File
> "/home/stefan/u-boot_master/tools/patman/../patman/checkpatch.py", line
> 11, in 
>  from patman import gitutil
>File "/home/stefan/u-boot_master/tools/patman/../patman/gitutil.py",
> line 10, in 
>  from patman import checkpatch
> ImportError: cannot import name 'checkpatch'

OK I will try a new patch.

Which distribution are you using?

Regards,
Simon


[PATCH v2] patman: Avoid circular dependency between command and tools

2020-05-19 Thread Simon Glass
This seems to cause problems in some cases. Split the dependency by
copying the code to command.

Reported-by: Stefan Bosch 
Signed-off-by: Simon Glass 
---

Changes in v2:
- Update gitutil as well

 tools/patman/command.py | 7 +++
 tools/patman/gitutil.py | 1 -
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/patman/command.py b/tools/patman/command.py
index e67ac159e5..bf8ea6c8c3 100644
--- a/tools/patman/command.py
+++ b/tools/patman/command.py
@@ -5,7 +5,6 @@
 import os
 
 from patman import cros_subprocess
-from patman import tools
 
 """Shell command ease-ups for Python."""
 
@@ -35,9 +34,9 @@ class CommandResult:
 
 def ToOutput(self, binary):
 if not binary:
-self.stdout = tools.ToString(self.stdout)
-self.stderr = tools.ToString(self.stderr)
-self.combined = tools.ToString(self.combined)
+self.stdout = self.stdout.decode('utf-8')
+self.stderr = self.stderr.decode('utf-8')
+self.combined = self.combined.decode('utf-8')
 return self
 
 
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 770a051014..844f8759de 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -7,7 +7,6 @@ import os
 import subprocess
 import sys
 
-from patman import checkpatch
 from patman import command
 from patman import series
 from patman import settings
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH] psci: add 'static inline' to invoke_psci_fn() stub

2020-05-19 Thread Masahiro Yamada
Avoid potential multiple definitions when CONFIG_ARM_PSCI_FW
is disabled.

Signed-off-by: Masahiro Yamada 
---

 include/linux/psci.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/psci.h b/include/linux/psci.h
index 9433df836b..841dbc8da7 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -91,8 +91,8 @@
 unsigned long invoke_psci_fn(unsigned long a0, unsigned long a1,
 unsigned long a2, unsigned long a3);
 #else
-unsigned long invoke_psci_fn(unsigned long a0, unsigned long a1,
-unsigned long a2, unsigned long a3)
+static inline unsigned long invoke_psci_fn(unsigned long a0, unsigned long a1,
+  unsigned long a2, unsigned long a3)
 {
return PSCI_RET_DISABLED;
 }
-- 
2.25.1



Re: [PATCH 2/2] thermal: imx_scu_thermal: fix getting DT alert property value

2020-05-19 Thread Anatolij Gustschin
On Wed, 20 May 2020 00:05:01 +0200
Anatolij Gustschin ag...@denx.de wrote:
...
> When uclass_get_device_by_name() is used, then 
> imx_sc_thermal_ofdata_to_platdata()
> is called for "cpu-thermal0" device, here getting the list works
> and alert/critical pdata values are initialized properly.

This 2/2 patch can be superseded by patch:
 
http://patchwork.ozlabs.org/project/uboot/patch/20200519233144.2426-1-ag...@denx.de

--
Anatolij


[PATCH] cpu: imx8: use intended cpu-thermal device when getting temp value

2020-05-19 Thread Anatolij Gustschin
This fixes getting DT alert and critical pdata values in imx_scu_thermal
driver. On i.MX8QXP using not initialized alert pdata value resulted in
boot hang and endless loop outputting:
CPU Temperature (47200C) has beyond alert (0C), close to critical (0C) 
waiting...

While at it, preset CPU type values once to avoid multiple calls
of device_is_compatible() for same property.

Fixes: 3ee6ea443eb4 ("cpu: imx_cpu: Print the CPU temperature for iMX8QM A72")
Signed-off-by: Anatolij Gustschin 
---
This one supersedes the older patch here:
 
http://patchwork.ozlabs.org/project/uboot/patch/20200516203420.24409-2-ag...@denx.de

 drivers/cpu/imx8_cpu.c | 50 +-
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/cpu/imx8_cpu.c b/drivers/cpu/imx8_cpu.c
index 896e1ac776..adc4919d9e 100644
--- a/drivers/cpu/imx8_cpu.c
+++ b/drivers/cpu/imx8_cpu.c
@@ -18,6 +18,7 @@ struct cpu_imx_platdata {
const char *name;
const char *rev;
const char *type;
+   u32 cpu_rsrc;
u32 cpurev;
u32 freq_mhz;
u32 mpidr;
@@ -50,16 +51,23 @@ const char *get_imx8_rev(u32 rev)
}
 }
 
-const char *get_core_name(struct udevice *dev)
+static void set_core_data(struct udevice *dev)
 {
-   if (device_is_compatible(dev, "arm,cortex-a35"))
-   return "A35";
-   else if (device_is_compatible(dev, "arm,cortex-a53"))
-   return "A53";
-   else if (device_is_compatible(dev, "arm,cortex-a72"))
-   return "A72";
-   else
-   return "?";
+   struct cpu_imx_platdata *plat = dev_get_platdata(dev);
+
+   if (device_is_compatible(dev, "arm,cortex-a35")) {
+   plat->cpu_rsrc = SC_R_A35;
+   plat->name = "A35";
+   } else if (device_is_compatible(dev, "arm,cortex-a53")) {
+   plat->cpu_rsrc = SC_R_A53;
+   plat->name = "A53";
+   } else if (device_is_compatible(dev, "arm,cortex-a72")) {
+   plat->cpu_rsrc = SC_R_A72;
+   plat->name = "A72";
+   } else {
+   plat->cpu_rsrc = SC_R_A53;
+   plat->name = "?";
+   }
 }
 
 #if IS_ENABLED(CONFIG_IMX_SCU_THERMAL)
@@ -67,12 +75,12 @@ static int cpu_imx_get_temp(struct cpu_imx_platdata *plat)
 {
struct udevice *thermal_dev;
int cpu_tmp, ret;
+   int idx = 1; /* use "cpu-thermal0" device */
 
-   if (!strcmp(plat->name, "A72"))
-   ret = uclass_get_device(UCLASS_THERMAL, 1, _dev);
-   else
-   ret = uclass_get_device(UCLASS_THERMAL, 0, _dev);
+   if (plat->cpu_rsrc == SC_R_A72)
+   idx = 2; /* use "cpu-thermal1" device */
 
+   ret = uclass_get_device(UCLASS_THERMAL, idx, _dev);
if (!ret) {
ret = thermal_get_temp(thermal_dev, _tmp);
if (ret)
@@ -180,19 +188,11 @@ static const struct udevice_id cpu_imx8_ids[] = {
 
 static ulong imx8_get_cpu_rate(struct udevice *dev)
 {
+   struct cpu_imx_platdata *plat = dev_get_platdata(dev);
ulong rate;
-   int ret, type;
-
-   if (device_is_compatible(dev, "arm,cortex-a35"))
-   type = SC_R_A35;
-   else if (device_is_compatible(dev, "arm,cortex-a53"))
-   type = SC_R_A53;
-   else if (device_is_compatible(dev, "arm,cortex-a72"))
-   type = SC_R_A72;
-   else
-   return 0;
+   int ret;
 
-   ret = sc_pm_get_clock_rate(-1, type, SC_PM_CLK_CPU,
+   ret = sc_pm_get_clock_rate(-1, plat->cpu_rsrc, SC_PM_CLK_CPU,
   (sc_pm_clock_rate_t *));
if (ret) {
printf("Could not read CPU frequency: %d\n", ret);
@@ -207,9 +207,9 @@ static int imx8_cpu_probe(struct udevice *dev)
struct cpu_imx_platdata *plat = dev_get_platdata(dev);
u32 cpurev;
 
+   set_core_data(dev);
cpurev = get_cpu_rev();
plat->cpurev = cpurev;
-   plat->name = get_core_name(dev);
plat->rev = get_imx8_rev(cpurev & 0xFFF);
plat->type = get_imx8_type((cpurev & 0xFF000) >> 12);
plat->freq_mhz = imx8_get_cpu_rate(dev) / 100;
-- 
2.17.1



[PATCH 25/26] x86: minnowmax: Enable the copy framebuffer

2020-05-19 Thread Simon Glass
Update the video driver to support this feature and enable it on
minnowmax to speed up the display.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from over 13 seconds to
300ms, at 1280x1024.

Signed-off-by: Simon Glass 
---

 configs/minnowmax_defconfig |  2 +-
 drivers/video/vesa.c| 30 +-
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig
index 127fd5d53e..19528c4641 100644
--- a/configs/minnowmax_defconfig
+++ b/configs/minnowmax_defconfig
@@ -59,6 +59,6 @@ CONFIG_RTL8169=y
 CONFIG_SPI=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
+CONFIG_VIDEO_COPY=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_11B=y
-CONFIG_CONSOLE_SCROLL_LINES=5
diff --git a/drivers/video/vesa.c b/drivers/video/vesa.c
index 6c03611e80..9656326bdb 100644
--- a/drivers/video/vesa.c
+++ b/drivers/video/vesa.c
@@ -5,12 +5,39 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
 
 static int vesa_video_probe(struct udevice *dev)
 {
-   return vbe_setup_video(dev, NULL);
+   struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
+   ulong fbbase;
+   int ret;
+
+   ret = vbe_setup_video(dev, NULL);
+   if (ret)
+   return log_ret(ret);
+
+   /* Use write-combining for the graphics memory, 256MB */
+   fbbase = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;
+   mtrr_add_request(MTRR_TYPE_WRCOMB, fbbase, 256 << 20);
+   mtrr_commit(true);
+
+   return 0;
+}
+
+static int vesa_video_bind(struct udevice *dev)
+{
+   struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
+
+   /* Set the maximum supported resolution */
+   uc_plat->size = 2560 * 1600 * 4;
+   log_debug("%s: Frame buffer size %x\n", __func__, uc_plat->size);
+
+   return 0;
 }
 
 static const struct udevice_id vesa_video_ids[] = {
@@ -22,6 +49,7 @@ U_BOOT_DRIVER(vesa_video) = {
.name   = "vesa_video",
.id = UCLASS_VIDEO,
.of_match = vesa_video_ids,
+   .bind   = vesa_video_bind,
.probe  = vesa_video_probe,
 };
 
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 26/26] x86: minnowmax: Drop screen resolution to 1024x768

2020-05-19 Thread Simon Glass
This seems like a more reasonable resolution for this board, since it is
quite slow. It also allows it to work with a 5" LCD display in my lab.

Signed-off-by: Simon Glass 
---

 configs/minnowmax_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig
index 19528c4641..cce9ee6fea 100644
--- a/configs/minnowmax_defconfig
+++ b/configs/minnowmax_defconfig
@@ -61,4 +61,4 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_VIDEO_COPY=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
-CONFIG_FRAMEBUFFER_VESA_MODE_11B=y
+CONFIG_FRAMEBUFFER_VESA_MODE_118=y
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 22/26] x86: video: Support copy framebuffer with probed devices

2020-05-19 Thread Simon Glass
For PCI video devices that are not mentioned in the devicetree, U-Boot
does not bind a driver before relocation, since PCI is not fully probed
at that point. Furthermore it is possible for the video device to be on
a secondary bus which is not even scanned.

This is fine if the framebuffer is allocated in fixed memory, as it
normally is on x86. But when using this as a copy framebuffer, we also
need U-Boot to allocate its own cached framebuffer for working in. Since
the video driver is never bound before relocation, the framebuffer size
is never set and U-Boot does no allocation.

Add a new CONFIG option to reserve 16MB of memory for this eventuality.
This allows vesa devices to use the copy framebuffer.

Signed-off-by: Simon Glass 
---

 drivers/video/Kconfig| 19 +++
 drivers/video/video-uclass.c |  5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 1cf63efd48..3e65052359 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -14,6 +14,25 @@ config DM_VIDEO
  option compiles in the video uclass and routes all LCD/video access
  through this.
 
+config VIDEO_PCI_DEFAULT_FB_SIZE
+   hex "Default framebuffer size to use if no drivers request it"
+   depends on DM_VIDEO
+   default 0x100 if X86 && PCI
+   default 0 if !(X86 && PCI)
+   help
+ Generally, video drivers request the amount of memory they need for
+ the frame buffer when they are bound, by setting the size field in
+ struct video_uc_platdata. That memory is then reserved for use after
+ relocation. But PCI drivers cannot be bound before relocation unless
+ they are mentioned in the devicetree.
+
+ With this value set appropriately, it is possible for PCI video
+ devices to have a framebuffer allocated by U-Boot.
+
+ Note: the framebuffer needs to be large enough to store all pixels at
+ maximum resolution. For example, at 1920 x 1200 with 32 bits per
+ pixel, 2560 * 1600 * 32 / 8 = 0xfa bytes are needed.
+
 config VIDEO_COPY
bool "Enable copying the frame buffer to a hardware copy"
depends on DM_VIDEO
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index aa543cb5df..b5a03042c2 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -97,6 +97,11 @@ int video_reserve(ulong *addrp)
debug("%s: Reserving %lx bytes at %lx for video device '%s'\n",
  __func__, size, *addrp, dev->name);
}
+
+   /* Allocate space for PCI video devices in case there were not bound */
+   if (*addrp == gd->video_top)
+   *addrp -= CONFIG_VIDEO_PCI_DEFAULT_FB_SIZE;
+
gd->video_bottom = *addrp;
debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
  gd->video_top);
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 23/26] x86: chromebook_samus: Enable the copy framebuffer

2020-05-19 Thread Simon Glass
Update the video driver to support this feature and enable it on samus.
Also remove the multi-line scrolling since normal scrolling is fast enough
now.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 430ms to 12ms.

Signed-off-by: Simon Glass 
---

 configs/chromebook_samus_defconfig |  2 +-
 drivers/video/broadwell_igd.c  | 16 +++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/configs/chromebook_samus_defconfig 
b/configs/chromebook_samus_defconfig
index fb4d88028c..13058ea7d7 100644
--- a/configs/chromebook_samus_defconfig
+++ b/configs/chromebook_samus_defconfig
@@ -67,7 +67,7 @@ CONFIG_SPI=y
 CONFIG_TPM_TIS_LPC=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
+CONFIG_VIDEO_COPY=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_11A=y
-CONFIG_CONSOLE_SCROLL_LINES=5
 CONFIG_TPM=y
diff --git a/drivers/video/broadwell_igd.c b/drivers/video/broadwell_igd.c
index 8e8fe9d9b3..df6a761d2d 100644
--- a/drivers/video/broadwell_igd.c
+++ b/drivers/video/broadwell_igd.c
@@ -664,6 +664,7 @@ static int broadwell_igd_probe(struct udevice *dev)
struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
bool is_broadwell;
+   ulong fbbase;
int ret;
 
if (!ll_boot_init()) {
@@ -690,7 +691,8 @@ static int broadwell_igd_probe(struct udevice *dev)
return ret;
 
/* Use write-combining for the graphics memory, 256MB */
-   ret = mtrr_add_request(MTRR_TYPE_WRCOMB, plat->base, 256 << 20);
+   fbbase = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;
+   ret = mtrr_add_request(MTRR_TYPE_WRCOMB, fbbase, 256 << 20);
if (!ret)
ret = mtrr_commit(true);
if (ret && ret != -ENOSYS) {
@@ -752,6 +754,17 @@ static int broadwell_igd_ofdata_to_platdata(struct udevice 
*dev)
return 0;
 }
 
+static int broadwell_igd_bind(struct udevice *dev)
+{
+   struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
+
+   /* Set the maximum supported resolution */
+   uc_plat->size = 2560 * 1600 * 4;
+   log_debug("%s: Frame buffer size %x\n", __func__, uc_plat->size);
+
+   return 0;
+}
+
 static const struct video_ops broadwell_igd_ops = {
 };
 
@@ -766,6 +779,7 @@ U_BOOT_DRIVER(broadwell_igd) = {
.of_match = broadwell_igd_ids,
.ops= _igd_ops,
.ofdata_to_platdata = broadwell_igd_ofdata_to_platdata,
+   .bind   = broadwell_igd_bind,
.probe  = broadwell_igd_probe,
.priv_auto_alloc_size   = sizeof(struct broadwell_igd_priv),
.platdata_auto_alloc_size   = sizeof(struct broadwell_igd_plat),
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 24/26] x86: chromebook_link: Enable the copy framebuffer

2020-05-19 Thread Simon Glass
Update the video driver to support this feature and enable it on link.
Also remove the multi-line scrolling since normal scrolling is fast enough
now.

With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 930ms to 29ms.

Signed-off-by: Simon Glass 
---

 configs/chromebook_link_defconfig |  2 +-
 drivers/video/ivybridge_igd.c | 26 --
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/configs/chromebook_link_defconfig 
b/configs/chromebook_link_defconfig
index de4186cdf2..215185c974 100644
--- a/configs/chromebook_link_defconfig
+++ b/configs/chromebook_link_defconfig
@@ -62,10 +62,10 @@ CONFIG_SPI=y
 CONFIG_TPM_TIS_LPC=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
+CONFIG_VIDEO_COPY=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_11A=y
 CONFIG_VIDEO_IVYBRIDGE_IGD=y
-CONFIG_CONSOLE_SCROLL_LINES=5
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_TPM=y
 # CONFIG_EFI_LOADER is not set
diff --git a/drivers/video/ivybridge_igd.c b/drivers/video/ivybridge_igd.c
index 4c57e311d1..2587f53ac1 100644
--- a/drivers/video/ivybridge_igd.c
+++ b/drivers/video/ivybridge_igd.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -722,7 +723,6 @@ static int gma_func0_init(struct udevice *dev)
 {
struct udevice *nbridge;
void *gtt_bar;
-   ulong base;
u32 reg32;
int ret;
int rev;
@@ -742,11 +742,6 @@ static int gma_func0_init(struct udevice *dev)
reg32 |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO;
dm_pci_write_config32(dev, PCI_COMMAND, reg32);
 
-   /* Use write-combining for the graphics memory, 256MB */
-   base = dm_pci_read_bar32(dev, 2);
-   mtrr_add_request(MTRR_TYPE_WRCOMB, base, 256 << 20);
-   mtrr_commit(true);
-
gtt_bar = (void *)(ulong)dm_pci_read_bar32(dev, 0);
debug("GT bar %p\n", gtt_bar);
ret = gma_pm_init_pre_vbios(gtt_bar, rev);
@@ -758,6 +753,8 @@ static int gma_func0_init(struct udevice *dev)
 
 static int bd82x6x_video_probe(struct udevice *dev)
 {
+   struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
+   ulong fbbase;
void *gtt_bar;
int ret, rev;
 
@@ -774,6 +771,22 @@ static int bd82x6x_video_probe(struct udevice *dev)
if (ret)
return ret;
 
+   /* Use write-combining for the graphics memory, 256MB */
+   fbbase = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;
+   mtrr_add_request(MTRR_TYPE_WRCOMB, fbbase, 256 << 20);
+   mtrr_commit(true);
+
+   return 0;
+}
+
+static int bd82x6x_video_bind(struct udevice *dev)
+{
+   struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
+
+   /* Set the maximum supported resolution */
+   uc_plat->size = 2560 * 1600 * 4;
+   log_debug("%s: Frame buffer size %x\n", __func__, uc_plat->size);
+
return 0;
 }
 
@@ -786,5 +799,6 @@ U_BOOT_DRIVER(bd82x6x_video) = {
.name   = "bd82x6x_video",
.id = UCLASS_VIDEO,
.of_match = bd82x6x_video_ids,
+   .bind   = bd82x6x_video_bind,
.probe  = bd82x6x_video_probe,
 };
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 20/26] x86: fsp: video: Allocate a frame buffer when needed

2020-05-19 Thread Simon Glass
When the copy framebuffer is in use, we must also have the standard U-Boot
framebuffer available. Update the FSP driver to support this.

Signed-off-by: Simon Glass 
---

 arch/x86/lib/fsp/fsp_graphics.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c
index 70224c1a48..4eaa4fa6d4 100644
--- a/arch/x86/lib/fsp/fsp_graphics.c
+++ b/arch/x86/lib/fsp/fsp_graphics.c
@@ -116,6 +116,16 @@ err:
return ret;
 }
 
+static int fsp_video_bind(struct udevice *dev)
+{
+   struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
+
+   /* Set the maximum supported resolution */
+   plat->size = 2560 * 1600 * 4;
+
+   return 0;
+}
+
 static const struct udevice_id fsp_video_ids[] = {
{ .compatible = "fsp-fb" },
{ }
@@ -125,7 +135,9 @@ U_BOOT_DRIVER(fsp_video) = {
.name   = "fsp_video",
.id = UCLASS_VIDEO,
.of_match = fsp_video_ids,
+   .bind   = fsp_video_bind,
.probe  = fsp_video_probe,
+   .flags  = DM_FLAG_PRE_RELOC,
 };
 
 static struct pci_device_id fsp_video_supported[] = {
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 21/26] video: Correctly handle multiple framebuffers

2020-05-19 Thread Simon Glass
At present video_bottom is set to the bottom of each framebuffer when it
is allocated. This is not correct, since it should hold the bottom of the
entire area available for framebuffers.

Fix this by adding a private address in the uclass which keeps track of
the next available spot for a framebuffer.

Signed-off-by: Simon Glass 
---

 drivers/video/video-uclass.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 4d6f950eab..aa543cb5df 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -46,6 +46,19 @@
  */
 DECLARE_GLOBAL_DATA_PTR;
 
+/**
+ * struct video_uc_priv - Information for the video uclass
+ *
+ * @video_ptr: Current allocation position of the video framebuffer pointer.
+ * While binding devices after relocation, this points to the next
+ * available address to use for a device's framebuffer. It starts at
+ * gd->video_top and works downwards, running out of space when it hits
+ * gd->video_bottom.
+ */
+struct video_uc_priv {
+   ulong video_ptr;
+};
+
 void video_set_flush_dcache(struct udevice *dev, bool flush)
 {
struct video_priv *priv = dev_get_uclass_priv(dev);
@@ -350,12 +363,21 @@ static int video_post_probe(struct udevice *dev)
 /* Post-relocation, allocate memory for the frame buffer */
 static int video_post_bind(struct udevice *dev)
 {
-   ulong addr = gd->video_top;
+   struct video_uc_priv *uc_priv;
+   ulong addr;
ulong size;
 
/* Before relocation there is nothing to do here */
if (!(gd->flags & GD_FLG_RELOC))
return 0;
+
+   /* Set up the video pointer, if this is the first device */
+   uc_priv = dev->uclass->priv;
+   if (!uc_priv->video_ptr)
+   uc_priv->video_ptr = gd->video_top;
+
+   /* Allocate framebuffer space for this device */
+   addr = uc_priv->video_ptr;
size = alloc_fb(dev, );
if (addr < gd->video_bottom) {
/* Device tree node may need the 'u-boot,dm-pre-reloc' or
@@ -367,7 +389,7 @@ static int video_post_bind(struct udevice *dev)
}
debug("%s: Claiming %lx bytes at %lx for video device '%s'\n",
  __func__, size, addr, dev->name);
-   gd->video_bottom = addr;
+   uc_priv->video_ptr = addr;
 
return 0;
 }
@@ -380,6 +402,7 @@ UCLASS_DRIVER(video) = {
.pre_probe  = video_pre_probe,
.post_probe = video_post_probe,
.pre_remove = video_pre_remove,
+   .priv_auto_alloc_size   = sizeof(struct video_uc_priv),
.per_device_auto_alloc_size = sizeof(struct video_priv),
.per_device_platdata_auto_alloc_size = sizeof(struct video_uc_platdata),
 };
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 17/26] video: Add comments to struct sandbox_sdl_plat

2020-05-19 Thread Simon Glass
This struct is not commented but needs it. Also fix the comment in
check_vidconsole_output() about the encoding for the rotation value.

Signed-off-by: Simon Glass 
---

 include/dm/test.h | 14 +-
 test/dm/video.c   |  3 ++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/include/dm/test.h b/include/dm/test.h
index f0f36624ce..d39686cde2 100644
--- a/include/dm/test.h
+++ b/include/dm/test.h
@@ -159,7 +159,19 @@ enum {
 /* Declare a new driver model test */
 #define DM_TEST(_name, _flags) UNIT_TEST(_name, _flags, dm_test)
 
-/* This platform data is needed in tests, so declare it here */
+/*
+ * struct sandbox_sdl_plat - Platform data for the SDL video driver
+ *
+ * This platform data is needed in tests, so declare it here
+ *
+ * @xres: Width of display in pixels
+ * @yres: Height of display in pixels
+ * @bpix: Log2 of bits per pixel (enum video_log2_bpp)
+ * @rot: Console rotation (0=normal orientation, 1=90 degrees clockwise,
+ * 2=upside down, 3=90 degree counterclockwise)
+ * @vidconsole_drv_name: Name of video console driver (set by tests)
+ * @font_size: Console font size to select (set by tests)
+ */
 struct sandbox_sdl_plat {
int xres;
int yres;
diff --git a/test/dm/video.c b/test/dm/video.c
index 68f5ba44e7..729c31b47d 100644
--- a/test/dm/video.c
+++ b/test/dm/video.c
@@ -188,7 +188,8 @@ DM_TEST(dm_test_video_ansi, DM_TESTF_SCAN_PDATA | 
DM_TESTF_SCAN_FDT);
  * check_vidconsole_output() - Run a text console test
  *
  * @uts:   Test state
- * @rot:   Console rotation (0, 90, 180, 270)
+ * @rot:   Console rotation (0=normal orientation, 1=90 degrees clockwise,
+ * 2=upside down, 3=90 degree counterclockwise)
  * @wrap_size: Expected size of compressed frame buffer for the wrap test
  * @scroll_size: Same for the scroll test
  * @return 0 on success
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 18/26] video: sandbox: Add support for the copy framebuffer

2020-05-19 Thread Simon Glass
Enable this feature on sandbox by updating the SDL driver to have two
framebuffers.

Update the video tests to check that the copy framebuffer is kept in sync.

Signed-off-by: Simon Glass 
---

 configs/sandbox_defconfig   |  1 +
 drivers/video/sandbox_sdl.c |  9 +-
 test/dm/video.c | 55 +++--
 3 files changed, 43 insertions(+), 22 deletions(-)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 9445d78118..ea567506e5 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -215,6 +215,7 @@ CONFIG_DM_USB=y
 CONFIG_USB_EMUL=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_COPY=y
 CONFIG_CONSOLE_ROTATION=y
 CONFIG_CONSOLE_TRUETYPE=y
 CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y
diff --git a/drivers/video/sandbox_sdl.c b/drivers/video/sandbox_sdl.c
index c678e728db..f529a350fb 100644
--- a/drivers/video/sandbox_sdl.c
+++ b/drivers/video/sandbox_sdl.c
@@ -23,6 +23,7 @@ enum {
 
 static int sandbox_sdl_probe(struct udevice *dev)
 {
+   struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
struct sandbox_sdl_plat *plat = dev_get_platdata(dev);
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct sandbox_state *state = state_get_current();
@@ -40,6 +41,8 @@ static int sandbox_sdl_probe(struct udevice *dev)
uc_priv->rot = plat->rot;
uc_priv->vidconsole_drv_name = plat->vidconsole_drv_name;
uc_priv->font_size = plat->font_size;
+   if (IS_ENABLED(CONFIG_VIDEO_COPY))
+   uc_plat->copy_base = uc_plat->base - uc_plat->size / 2;
 
return 0;
 }
@@ -55,7 +58,11 @@ static int sandbox_sdl_bind(struct udevice *dev)
plat->bpix = dev_read_u32_default(dev, "log2-depth", VIDEO_BPP16);
plat->rot = dev_read_u32_default(dev, "rotate", 0);
uc_plat->size = plat->xres * plat->yres * (1 << plat->bpix) / 8;
-   debug("%s: Frame buffer size %x\n", __func__, uc_plat->size);
+
+   /* Allow space for two buffers, the lower one being the copy buffer */
+   log_debug("Frame buffer size %x\n", uc_plat->size);
+   if (IS_ENABLED(CONFIG_VIDEO_COPY))
+   uc_plat->size *= 2;
 
return ret;
 }
diff --git a/test/dm/video.c b/test/dm/video.c
index 729c31b47d..19f78b6239 100644
--- a/test/dm/video.c
+++ b/test/dm/video.c
@@ -51,12 +51,18 @@ DM_TEST(dm_test_video_base, DM_TESTF_SCAN_PDATA | 
DM_TESTF_SCAN_FDT);
  * size of the compressed data. This provides a pretty good level of
  * certainty and the resulting tests need only check a single value.
  *
+ * If the copy framebuffer is enabled, this compares it to the main framebuffer
+ * too.
+ *
+ * @uts:   Test state
  * @dev:   Video device
  * @return compressed size of the frame buffer, or -ve on error
  */
-static int compress_frame_buffer(struct udevice *dev)
+static int compress_frame_buffer(struct unit_test_state *uts,
+struct udevice *dev)
 {
struct video_priv *priv = dev_get_uclass_priv(dev);
+   struct video_priv *uc_priv = dev_get_uclass_priv(dev);
uint destlen;
void *dest;
int ret;
@@ -72,6 +78,13 @@ static int compress_frame_buffer(struct udevice *dev)
if (ret)
return ret;
 
+   /* Check here that the copy frame buffer is working correctly */
+   if (IS_ENABLED(CONFIG_VIDEO_COPY)) {
+   ut_assertf(!memcmp(uc_priv->fb, uc_priv->copy_fb,
+  uc_priv->fb_size),
+  "Copy framebuffer does not match fb");
+   }
+
return destlen;
 }
 
@@ -110,25 +123,25 @@ static int dm_test_video_text(struct unit_test_state *uts)
 
ut_assertok(select_vidconsole(uts, "vidconsole0"));
ut_assertok(uclass_get_device(UCLASS_VIDEO, 0, ));
-   ut_asserteq(46, compress_frame_buffer(dev));
+   ut_asserteq(46, compress_frame_buffer(uts, dev));
 
ut_assertok(uclass_get_device(UCLASS_VIDEO_CONSOLE, 0, ));
vidconsole_putc_xy(con, 0, 0, 'a');
-   ut_asserteq(79, compress_frame_buffer(dev));
+   ut_asserteq(79, compress_frame_buffer(uts, dev));
 
vidconsole_putc_xy(con, 0, 0, ' ');
-   ut_asserteq(46, compress_frame_buffer(dev));
+   ut_asserteq(46, compress_frame_buffer(uts, dev));
 
for (i = 0; i < 20; i++)
vidconsole_putc_xy(con, VID_TO_POS(i * 8), 0, ' ' + i);
-   ut_asserteq(273, compress_frame_buffer(dev));
+   ut_asserteq(273, compress_frame_buffer(uts, dev));
 
vidconsole_set_row(con, 0, WHITE);
-   ut_asserteq(46, compress_frame_buffer(dev));
+   ut_asserteq(46, compress_frame_buffer(uts, dev));
 
for (i = 0; i < 20; i++)
vidconsole_putc_xy(con, VID_TO_POS(i * 8), 0, ' ' + i);
-   ut_asserteq(273, compress_frame_buffer(dev));
+   ut_asserteq(273, compress_frame_buffer(uts, dev));
 
return 0;
 }
@@ -144,7 +157,7 @@ static int 

[PATCH 19/26] video: pci: Set up the copy framebuffer

2020-05-19 Thread Simon Glass
When using a copy framebuffer we need to tell the video subsystem its
address. U-Boot's normally allocated framebuffer is used as the working
buffer, but nothing is displayed until it is copied to the copy
framebuffer.

For this to work the video driver must request that a framebuffer be
allocated separately from the hardware framebuffer, so add a check for
that.

Also add a log category so that logging appears correctly.

Signed-off-by: Simon Glass 
---

 drivers/pci/pci_rom.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 6a9bc49978..fa29d69e85 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -22,6 +22,8 @@
  * Copyright 1997 -- 1999 Martin Mares 
  */
 
+#define LOG_CATEGORY UCLASS_PCI
+
 #include 
 #include 
 #include 
@@ -344,7 +346,16 @@ int vbe_setup_video_priv(struct vesa_mode_info *vesa,
default:
return -EPROTONOSUPPORT;
}
-   plat->base = vesa->phys_base_ptr;
+
+   /* Use double buffering if enabled */
+   if (IS_ENABLED(CONFIG_VIDEO_COPY)) {
+   if (!plat->base)
+   return log_msg_ret("copy", -ENFILE);
+   plat->copy_base = vesa->phys_base_ptr;
+   } else {
+   plat->base = vesa->phys_base_ptr;
+   }
+   log_debug("base = %lx, copy_base = %lx\n", plat->base, plat->copy_base);
plat->size = vesa->bytes_per_scanline * vesa->y_resolution;
 
return 0;
@@ -372,6 +383,15 @@ int vbe_setup_video(struct udevice *dev, int 
(*int15_handler)(void))
 
ret = vbe_setup_video_priv(_info.vesa, uc_priv, plat);
if (ret) {
+   if (ret == -ENFILE) {
+   /*
+* See video-uclass.c for how to set up reserved memory
+* in your video driver
+*/
+   log_err("CONFIG_VIDEO_COPY enabled but driver '%s' set 
up no reserved memory\n",
+   dev->driver->name);
+   }
+
debug("No video mode configured\n");
return ret;
}
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 15/26] video: Update rotated console to support copy buffer

2020-05-19 Thread Simon Glass
Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass 
---

 drivers/video/console_rotate.c | 83 --
 1 file changed, 60 insertions(+), 23 deletions(-)

diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c
index da0ce7b9ce..36c8d0609d 100644
--- a/drivers/video/console_rotate.c
+++ b/drivers/video/console_rotate.c
@@ -15,11 +15,13 @@ static int console_set_row_1(struct udevice *dev, uint row, 
int clr)
 {
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
int pbytes = VNBYTES(vid_priv->bpix);
-   void *line;
+   void *start, *line;
int i, j;
+   int ret;
 
-   line = vid_priv->fb + vid_priv->line_length -
+   start = vid_priv->fb + vid_priv->line_length -
(row + 1) * VIDEO_FONT_HEIGHT * pbytes;
+   line = start;
for (j = 0; j < vid_priv->ysize; j++) {
switch (vid_priv->bpix) {
case VIDEO_BPP8:
@@ -51,6 +53,9 @@ static int console_set_row_1(struct udevice *dev, uint row, 
int clr)
}
line += vid_priv->line_length;
}
+   ret = vidconsole_sync_copy(dev, start, line);
+   if (ret)
+   return ret;
 
return 0;
 }
@@ -62,7 +67,7 @@ static int console_move_rows_1(struct udevice *dev, uint 
rowdst, uint rowsrc,
int pbytes = VNBYTES(vid_priv->bpix);
void *dst;
void *src;
-   int j;
+   int j, ret;
 
dst = vid_priv->fb + vid_priv->line_length -
(rowdst + count) * VIDEO_FONT_HEIGHT * pbytes;
@@ -70,7 +75,10 @@ static int console_move_rows_1(struct udevice *dev, uint 
rowdst, uint rowsrc,
(rowsrc + count) * VIDEO_FONT_HEIGHT * pbytes;
 
for (j = 0; j < vid_priv->ysize; j++) {
-   memmove(dst, src, VIDEO_FONT_HEIGHT * pbytes * count);
+   ret = vidconsole_memmove(dev, dst, src,
+VIDEO_FONT_HEIGHT * pbytes * count);
+   if (ret)
+   return ret;
src += vid_priv->line_length;
dst += vid_priv->line_length;
}
@@ -85,13 +93,14 @@ static int console_putc_xy_1(struct udevice *dev, uint 
x_frac, uint y, char ch)
struct video_priv *vid_priv = dev_get_uclass_priv(vid);
uchar *pfont = video_fontdata + (u8)ch * VIDEO_FONT_HEIGHT;
int pbytes = VNBYTES(vid_priv->bpix);
-   int i, col, x, linenum;
+   int i, col, x, linenum, ret;
int mask = 0x80;
-   void *line;
+   void *start, *line;
 
linenum = VID_TO_PIXEL(x_frac) + 1;
x = y + 1;
-   line = vid_priv->fb + linenum * vid_priv->line_length - x * pbytes;
+   start = vid_priv->fb + linenum * vid_priv->line_length - x * pbytes;
+   line = start;
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
 
@@ -136,6 +145,10 @@ static int console_putc_xy_1(struct udevice *dev, uint 
x_frac, uint y, char ch)
line += vid_priv->line_length;
mask >>= 1;
}
+   /* We draw backwards from 'start, so account for the first line */
+   ret = vidconsole_sync_copy(dev, start - vid_priv->line_length, line);
+   if (ret)
+   return ret;
 
return VID_TO_POS(VIDEO_FONT_WIDTH);
 }
@@ -144,12 +157,13 @@ static int console_putc_xy_1(struct udevice *dev, uint 
x_frac, uint y, char ch)
 static int console_set_row_2(struct udevice *dev, uint row, int clr)
 {
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
-   void *line;
+   void *start, *line, *end;
int pixels = VIDEO_FONT_HEIGHT * vid_priv->xsize;
-   int i;
+   int i, ret;
 
-   line = vid_priv->fb + vid_priv->ysize * vid_priv->line_length -
+   start = vid_priv->fb + vid_priv->ysize * vid_priv->line_length -
(row + 1) * VIDEO_FONT_HEIGHT * vid_priv->line_length;
+   line = start;
switch (vid_priv->bpix) {
case VIDEO_BPP8:
if (IS_ENABLED(CONFIG_VIDEO_BPP8)) {
@@ -157,6 +171,7 @@ static int console_set_row_2(struct udevice *dev, uint row, 
int clr)
 
for (i = 0; i < pixels; i++)
*dst++ = clr;
+   end = dst;
break;
}
case VIDEO_BPP16:
@@ -165,6 +180,7 @@ static int console_set_row_2(struct udevice *dev, uint row, 
int clr)
 
for (i = 0; i < pixels; i++)
*dst++ = clr;
+   end = dst;
break;
}
case VIDEO_BPP32:
@@ -173,11 +189,15 @@ static int console_set_row_2(struct 

[PATCH 16/26] video: Update the copy framebuffer when writing bitmaps

2020-05-19 Thread Simon Glass
Adjust the bitmap code to sync to the copy framebuffer when done.

Signed-off-by: Simon Glass 
---

 drivers/video/video_bmp.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/video/video_bmp.c b/drivers/video/video_bmp.c
index eb9636541d..732ce3bcc1 100644
--- a/drivers/video/video_bmp.c
+++ b/drivers/video/video_bmp.c
@@ -192,7 +192,7 @@ int video_bmp_display(struct udevice *dev, ulong bmp_image, 
int x, int y,
struct video_priv *priv = dev_get_uclass_priv(dev);
ushort *cmap_base = NULL;
int i, j;
-   uchar *fb;
+   uchar *start, *fb;
struct bmp_image *bmp = map_sysmem(bmp_image, 0);
uchar *bmap;
ushort padded_width;
@@ -201,6 +201,7 @@ int video_bmp_display(struct udevice *dev, ulong bmp_image, 
int x, int y,
unsigned colours, bpix, bmp_bpix;
struct bmp_color_table_entry *palette;
int hdr_size;
+   int ret;
 
if (!bmp || !(bmp->header.signature[0] == 'B' &&
bmp->header.signature[1] == 'M')) {
@@ -259,8 +260,11 @@ int video_bmp_display(struct udevice *dev, ulong 
bmp_image, int x, int y,
height = priv->ysize - y;
 
bmap = (uchar *)bmp + get_unaligned_le32(>header.data_offset);
-   fb = (uchar *)(priv->fb +
-   (y + height - 1) * priv->line_length + x * bpix / 8);
+   start = (uchar *)(priv->fb +
+   (y + height) * priv->line_length + x * bpix / 8);
+
+   /* Move back to the final line to be drawn */
+   fb = start - priv->line_length;
 
switch (bmp_bpix) {
case 1:
@@ -354,6 +358,12 @@ int video_bmp_display(struct udevice *dev, ulong 
bmp_image, int x, int y,
break;
};
 
+   /* Find the position of the top left of the image in the framebuffer */
+   fb = (uchar *)(priv->fb + y * priv->line_length + x * bpix / 8);
+   ret = video_sync_copy(dev, start, fb);
+   if (ret)
+   return log_ret(ret);
+
video_sync(dev, false);
 
return 0;
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 14/26] video: Update truetype console to support copy buffer

2020-05-19 Thread Simon Glass
Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass 
---

 drivers/video/console_truetype.c | 43 +++-
 1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/drivers/video/console_truetype.c b/drivers/video/console_truetype.c
index 5f7f03904b..22b2ea7191 100644
--- a/drivers/video/console_truetype.c
+++ b/drivers/video/console_truetype.c
@@ -127,9 +127,9 @@ static int console_truetype_set_row(struct udevice *dev, 
uint row, int clr)
 {
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
struct console_tt_priv *priv = dev_get_priv(dev);
-   void *line;
+   void *end, *line;
int pixels = priv->font_size * vid_priv->line_length;
-   int i;
+   int i, ret;
 
line = vid_priv->fb + row * priv->font_size * vid_priv->line_length;
switch (vid_priv->bpix) {
@@ -139,6 +139,7 @@ static int console_truetype_set_row(struct udevice *dev, 
uint row, int clr)
 
for (i = 0; i < pixels; i++)
*dst++ = clr;
+   end = dst;
break;
}
 #endif
@@ -148,6 +149,7 @@ static int console_truetype_set_row(struct udevice *dev, 
uint row, int clr)
 
for (i = 0; i < pixels; i++)
*dst++ = clr;
+   end = dst;
break;
}
 #endif
@@ -157,12 +159,16 @@ static int console_truetype_set_row(struct udevice *dev, 
uint row, int clr)
 
for (i = 0; i < pixels; i++)
*dst++ = clr;
+   end = dst;
break;
}
 #endif
default:
return -ENOSYS;
}
+   ret = vidconsole_sync_copy(dev, line, end);
+   if (ret)
+   return ret;
 
return 0;
 }
@@ -174,11 +180,14 @@ static int console_truetype_move_rows(struct udevice 
*dev, uint rowdst,
struct console_tt_priv *priv = dev_get_priv(dev);
void *dst;
void *src;
-   int i, diff;
+   int i, diff, ret;
 
dst = vid_priv->fb + rowdst * priv->font_size * vid_priv->line_length;
src = vid_priv->fb + rowsrc * priv->font_size * vid_priv->line_length;
-   memmove(dst, src, priv->font_size * vid_priv->line_length * count);
+   ret = vidconsole_memmove(dev, dst, src, priv->font_size *
+vid_priv->line_length * count);
+   if (ret)
+   return ret;
 
/* Scroll up our position history */
diff = (rowsrc - rowdst) * priv->font_size;
@@ -203,8 +212,8 @@ static int console_truetype_putc_xy(struct udevice *dev, 
uint x, uint y,
struct pos_info *pos;
u8 *bits, *data;
int advance;
-   void *line;
-   int row;
+   void *start, *end, *line;
+   int row, ret;
 
/* First get some basic metrics about this character */
stbtt_GetCodepointHMetrics(font, ch, , );
@@ -253,11 +262,12 @@ static int console_truetype_putc_xy(struct udevice *dev, 
uint x, uint y,
 
/* Figure out where to write the character in the frame buffer */
bits = data;
-   line = vid_priv->fb + y * vid_priv->line_length +
+   start = vid_priv->fb + y * vid_priv->line_length +
VID_TO_PIXEL(x) * VNBYTES(vid_priv->bpix);
linenum = priv->baseline + yoff;
if (linenum > 0)
-   line += linenum * vid_priv->line_length;
+   start += linenum * vid_priv->line_length;
+   line = start;
 
/*
 * Write a row at a time, converting the 8bpp image into the colour
@@ -286,6 +296,7 @@ static int console_truetype_putc_xy(struct udevice *dev, 
uint x, uint y,
*dst++ &= out;
bits++;
}
+   end = dst;
break;
}
 #endif
@@ -307,6 +318,7 @@ static int console_truetype_putc_xy(struct udevice *dev, 
uint x, uint y,
*dst++ &= out;
bits++;
}
+   end = dst;
break;
}
 #endif
@@ -317,6 +329,9 @@ static int console_truetype_putc_xy(struct udevice *dev, 
uint x, uint y,
 
line += vid_priv->line_length;
}
+   ret = vidconsole_sync_copy(dev, start, line);
+   if (ret)
+   return ret;
free(data);
 
return width_frac;
@@ -340,12 +355,13 @@ static int console_truetype_erase(struct udevice *dev, 
int xstart, int ystart,
  int xend, int yend, int clr)
 {
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
-   void *line;
+   void *start, *line;

[PATCH 13/26] video: Update normal console to support copy buffer

2020-05-19 Thread Simon Glass
Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.

Signed-off-by: Simon Glass 
---

 drivers/video/console_normal.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c
index c3f7ef8add..04f022491e 100644
--- a/drivers/video/console_normal.c
+++ b/drivers/video/console_normal.c
@@ -16,8 +16,9 @@
 static int console_normal_set_row(struct udevice *dev, uint row, int clr)
 {
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
-   void *line;
+   void *line, *end;
int pixels = VIDEO_FONT_HEIGHT * vid_priv->xsize;
+   int ret;
int i;
 
line = vid_priv->fb + row * VIDEO_FONT_HEIGHT * vid_priv->line_length;
@@ -28,6 +29,7 @@ static int console_normal_set_row(struct udevice *dev, uint 
row, int clr)
 
for (i = 0; i < pixels; i++)
*dst++ = clr;
+   end = dst;
break;
}
case VIDEO_BPP16:
@@ -36,6 +38,7 @@ static int console_normal_set_row(struct udevice *dev, uint 
row, int clr)
 
for (i = 0; i < pixels; i++)
*dst++ = clr;
+   end = dst;
break;
}
case VIDEO_BPP32:
@@ -44,11 +47,15 @@ static int console_normal_set_row(struct udevice *dev, uint 
row, int clr)
 
for (i = 0; i < pixels; i++)
*dst++ = clr;
+   end = dst;
break;
}
default:
return -ENOSYS;
}
+   ret = vidconsole_sync_copy(dev, line, end);
+   if (ret)
+   return ret;
 
return 0;
 }
@@ -59,10 +66,15 @@ static int console_normal_move_rows(struct udevice *dev, 
uint rowdst,
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
void *dst;
void *src;
+   int size;
+   int ret;
 
dst = vid_priv->fb + rowdst * VIDEO_FONT_HEIGHT * vid_priv->line_length;
src = vid_priv->fb + rowsrc * VIDEO_FONT_HEIGHT * vid_priv->line_length;
-   memmove(dst, src, VIDEO_FONT_HEIGHT * vid_priv->line_length * count);
+   size = VIDEO_FONT_HEIGHT * vid_priv->line_length * count;
+   ret = vidconsole_memmove(dev, dst, src, size);
+   if (ret)
+   return ret;
 
return 0;
 }
@@ -74,8 +86,13 @@ static int console_normal_putc_xy(struct udevice *dev, uint 
x_frac, uint y,
struct udevice *vid = dev->parent;
struct video_priv *vid_priv = dev_get_uclass_priv(vid);
int i, row;
-   void *line = vid_priv->fb + y * vid_priv->line_length +
+   void *start;
+   void *line;
+   int ret;
+
+   start = vid_priv->fb + y * vid_priv->line_length +
VID_TO_PIXEL(x_frac) * VNBYTES(vid_priv->bpix);
+   line = start;
 
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
@@ -126,6 +143,9 @@ static int console_normal_putc_xy(struct udevice *dev, uint 
x_frac, uint y,
}
line += vid_priv->line_length;
}
+   ret = vidconsole_sync_copy(dev, start, line);
+   if (ret)
+   return ret;
 
return VID_TO_POS(VIDEO_FONT_WIDTH);
 }
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 11/26] video: Clear the copy framebuffer when clearing the screen

2020-05-19 Thread Simon Glass
Update video_clear() to also sync to the copy framebuffer.

Signed-off-by: Simon Glass 
---

 drivers/video/video-uclass.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 0c97377ea9..4d6f950eab 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -94,6 +94,7 @@ int video_reserve(ulong *addrp)
 int video_clear(struct udevice *dev)
 {
struct video_priv *priv = dev_get_uclass_priv(dev);
+   int ret;
 
switch (priv->bpix) {
case VIDEO_BPP16:
@@ -118,6 +119,9 @@ int video_clear(struct udevice *dev)
memset(priv->fb, priv->colour_bg, priv->fb_size);
break;
}
+   ret = video_sync_copy(dev, priv->fb, priv->fb + priv->fb_size);
+   if (ret)
+   return ret;
 
return 0;
 }
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 12/26] video: Add helpers for vidconsole for the copy framebuffer

2020-05-19 Thread Simon Glass
Add a convenience function to call video_sync_copy() for a vidconsole.
Also add a memmove() helper, which does the memmove() as well as the sync.

Signed-off-by: Simon Glass 
---

 drivers/video/vidconsole-uclass.c | 22 ++
 include/video_console.h   | 49 +++
 2 files changed, 71 insertions(+)

diff --git a/drivers/video/vidconsole-uclass.c 
b/drivers/video/vidconsole-uclass.c
index e06912cf36..130c04bc27 100644
--- a/drivers/video/vidconsole-uclass.c
+++ b/drivers/video/vidconsole-uclass.c
@@ -629,6 +629,28 @@ UCLASS_DRIVER(vidconsole) = {
.per_device_auto_alloc_size = sizeof(struct vidconsole_priv),
 };
 
+#ifdef CONFIG_VIDEO_COPY
+int vidconsole_sync_copy(struct udevice *dev, void *from, void *to)
+{
+   struct udevice *vid = dev_get_parent(dev);
+
+   return video_sync_copy(vid, from, to);
+}
+
+int vidconsole_memmove(struct udevice *dev, void *dst, const void *src,
+  int size)
+{
+   int ret;
+
+   memmove(dst, src, size);
+   ret = vidconsole_sync_copy(dev, dst, dst + size);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+#endif
+
 void vidconsole_position_cursor(struct udevice *dev, unsigned col, unsigned 
row)
 {
struct vidconsole_priv *priv = dev_get_uclass_priv(dev);
diff --git a/include/video_console.h b/include/video_console.h
index d3bc063165..06b798ef10 100644
--- a/include/video_console.h
+++ b/include/video_console.h
@@ -256,4 +256,53 @@ void vidconsole_position_cursor(struct udevice *dev, 
unsigned col,
  */
 u32 vid_console_color(struct video_priv *priv, unsigned int idx);
 
+#ifdef CONFIG_VIDEO_COPY
+/**
+ * vidconsole_sync_copy() - Sync back to the copy framebuffer
+ *
+ * This ensures that the copy framebuffer has the same data as the framebuffer
+ * for a particular region. It should be called after the framebuffer is 
updated
+ *
+ * @from and @to can be in either order. The region between them is synced.
+ *
+ * @dev: Vidconsole device being updated
+ * @from: Start/end address within the framebuffer (->fb)
+ * @to: Other address within the frame buffer
+ * @return 0 if OK, -EFAULT if the start address is before the start of the
+ * frame buffer start
+ */
+int vidconsole_sync_copy(struct udevice *dev, void *from, void *to);
+
+/**
+ * vidconsole_memmove() - Perform a memmove() within the frame buffer
+ *
+ * This handles a memmove(), e.g. for scrolling. It also updates the copy
+ * framebuffer.
+ *
+ * @dev: Vidconsole device being updated
+ * @dst: Destination address within the framebuffer (->fb)
+ * @src: Source address within the framebuffer (->fb)
+ * @size: Number of bytes to transfer
+ * @return 0 if OK, -EFAULT if the start address is before the start of the
+ * frame buffer start
+ */
+int vidconsole_memmove(struct udevice *dev, void *dst, const void *src,
+  int size);
+#else
+static inline int vidconsole_sync_copy(struct udevice *dev, void *from,
+  void *to)
+{
+   return 0;
+}
+
+static inline int vidconsole_memmove(struct udevice *dev, void *dst,
+const void *src, int size)
+{
+   memmove(dst, src, size);
+
+   return 0;
+}
+
+#endif
+
 #endif
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 10/26] video: Set up the copy framebuffer when enabled

2020-05-19 Thread Simon Glass
This framebuffer is separately mapped. Update the video post-probe
function to set this up.

Signed-off-by: Simon Glass 
---

 drivers/video/video-uclass.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 9fbaa8db10..0c97377ea9 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -292,6 +292,9 @@ static int video_post_probe(struct udevice *dev)
 
priv->fb_size = priv->line_length * priv->ysize;
 
+   if (IS_ENABLED(CONFIG_VIDEO_COPY) && plat->copy_base)
+   priv->copy_fb = map_sysmem(plat->copy_base, plat->size);
+
/* Set up colors  */
video_set_default_colors(dev, false);
 
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 09/26] video: Add support for copying to a hardware framebuffer

2020-05-19 Thread Simon Glass
Some architectures use a cached framebuffer and flush the cache as needed
so that changes are visible. This is supported by U-Boot.

However x86 uses an uncached framebuffer with a 'write-combining' feature
to speed up writes.  Reads are permitted but they are extremely expensive.

Unfortunately, reading from the frame buffer is quite common, e.g. to
scroll it. This makes scrolling very slow.

Add a new feature which supports copying modified parts of the frame
buffer to the uncached hardware buffer. This speeds up scrolling by at
least 10x on x86 so the extra complexity cost seems worth it.

As a starting point, add the Kconfig, update the video structures to keep
track of the buffer and add a function to do the copy.

Signed-off-by: Simon Glass 
---

 drivers/video/Kconfig| 12 
 drivers/video/video-uclass.c | 54 
 include/video.h  | 29 +++
 3 files changed, 95 insertions(+)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 38123543a5..1cf63efd48 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -14,6 +14,18 @@ config DM_VIDEO
  option compiles in the video uclass and routes all LCD/video access
  through this.
 
+config VIDEO_COPY
+   bool "Enable copying the frame buffer to a hardware copy"
+   depends on DM_VIDEO
+   help
+ On some machines (e.g. x86), reading from the frame buffer is very
+ slow because it is uncached. To improve performance, this feature
+ allows the frame buffer to be kept in cached memory (allocated by
+ U-Boot) and then copied to the hardware frame-buffer as needed.
+
+ To use this, your video driver must set @copy_base in
+ struct video_uc_platdata.
+
 config BACKLIGHT_PWM
bool "Generic PWM based Backlight Driver"
depends on DM_VIDEO && DM_PWM
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index bf396d1091..9fbaa8db10 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -4,6 +4,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -200,6 +201,59 @@ int video_get_ysize(struct udevice *dev)
return priv->ysize;
 }
 
+#ifdef CONFIG_VIDEO_COPY
+int video_sync_copy(struct udevice *dev, void *from, void *to)
+{
+   struct video_priv *priv = dev_get_uclass_priv(dev);
+
+   if (priv->copy_fb) {
+   long offset, size;
+
+   /* Find the offset of the first byte to copy */
+   if ((ulong)to > (ulong)from) {
+   size = to - from;
+   offset = from - priv->fb;
+   } else {
+   size = from - to;
+   offset = to - priv->fb;
+   }
+
+   /*
+* Allow a bit of leeway for valid requests somewhere near the
+* frame buffer
+*/
+   if (offset < -priv->fb_size || offset > 2 * priv->fb_size) {
+#ifdef DEBUG
+   char str[80];
+
+   snprintf(str, sizeof(str),
+"[sync_copy fb=%p, from=%p, to=%p, 
offset=%lx]",
+priv->fb, from, to, offset);
+   console_puts_select_stderr(true, str);
+#endif
+   return -EFAULT;
+   }
+
+   /*
+* Silently crop the memcpy. This allows callers to avoid doing
+* this themselves. It is common for the end pointer to go a
+* few lines after the end of the frame buffer, since most of
+* the update algorithms terminate a line after their last write
+*/
+   if (offset + size > priv->fb_size) {
+   size = priv->fb_size - offset;
+   } else if (offset < 0) {
+   size += offset;
+   offset = 0;
+   }
+
+   memcpy(priv->copy_fb + offset, priv->fb + offset, size);
+   }
+
+   return 0;
+}
+#endif
+
 /* Set up the colour map */
 static int video_pre_probe(struct udevice *dev)
 {
diff --git a/include/video.h b/include/video.h
index 813b5653b0..1a0ffd8037 100644
--- a/include/video.h
+++ b/include/video.h
@@ -30,11 +30,14 @@ struct udevice;
  * buffer should start on. If 0, 1MB is assumed
  * @size: Frame-buffer size, in bytes
  * @base: Base address of frame buffer, 0 if not yet known
+ * @copy_base: Base address of a hardware copy of the frame buffer. See
+ * CONFIG_VIDEO_COPY.
  */
 struct video_uc_platdata {
uint align;
uint size;
ulong base;
+   ulong copy_base;
 };
 
 enum video_polarity {
@@ -75,6 +78,8 @@ enum video_log2_bpp {
  * @font_size: Font size in pixels (0 to use a default value)
  * @fb:Frame buffer
  * @fb_size:   Frame buffer size
+ * @copy_fb:   Copy of the frame buffer to 

[PATCH 07/26] video: Drop unnecessary #ifdef around vid_console_color()

2020-05-19 Thread Simon Glass
All of the functions in this file only apply if DM_VIDEO is enabled. Drop
the #ifdef as it just clutters things up. Add the needed forward
declaration.

Signed-off-by: Simon Glass 
---

 include/video_console.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/video_console.h b/include/video_console.h
index 0936ceaaf1..d3bc063165 100644
--- a/include/video_console.h
+++ b/include/video_console.h
@@ -8,6 +8,8 @@
 
 #include 
 
+struct video_priv;
+
 #define VID_FRAC_DIV   256
 
 #define VID_TO_PIXEL(x)((x) / VID_FRAC_DIV)
@@ -241,8 +243,6 @@ int vidconsole_put_string(struct udevice *dev, const char 
*str);
 void vidconsole_position_cursor(struct udevice *dev, unsigned col,
unsigned row);
 
-#ifdef CONFIG_DM_VIDEO
-
 /**
  * vid_console_color() - convert a color code to a pixel's internal
  * representation
@@ -257,5 +257,3 @@ void vidconsole_position_cursor(struct udevice *dev, 
unsigned col,
 u32 vid_console_color(struct video_priv *priv, unsigned int idx);
 
 #endif
-
-#endif
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 02/26] console: Add a way to output to serial only

2020-05-19 Thread Simon Glass
In the video drivers it is useful to print errors while debugging but
doing so risks an infinite loop as the debugging info itself may go
through the video drivers.

Add a new console function that prints information only to the serial
device, thus making it safe for use in debugging.

Signed-off-by: Simon Glass 
---

 common/console.c  | 28 ++--
 include/console.h | 13 +
 2 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/common/console.c b/common/console.c
index 1deca3cb78..31f46470d2 100644
--- a/common/console.c
+++ b/common/console.c
@@ -229,18 +229,34 @@ static void console_putc(int file, const char c)
}
 }
 
-static void console_puts_noserial(int file, const char *s)
+/**
+ * console_puts_select() - Output a string to all console devices
+ *
+ * @file: File number to output to (e,g, stdout, see stdio.h)
+ * @serial_only: true to output only to serial, false to output to everything
+ * else
+ * @s: String to output
+ */
+static void console_puts_select(int file, bool serial_only, const char *s)
 {
int i;
struct stdio_dev *dev;
 
for (i = 0; i < cd_count[file]; i++) {
+   bool is_serial;
+
dev = console_devices[file][i];
-   if (dev->puts != NULL && !console_dev_is_serial(dev))
+   is_serial = console_dev_is_serial(dev);
+   if (dev->puts && serial_only == is_serial)
dev->puts(dev, s);
}
 }
 
+void console_puts_select_stderr(bool serial_only, const char *s)
+{
+   console_puts_select(stderr, serial_only, s);
+}
+
 static void console_puts(int file, const char *s)
 {
int i;
@@ -275,9 +291,9 @@ static inline void console_putc(int file, const char c)
stdio_devices[file]->putc(stdio_devices[file], c);
 }
 
-static inline void console_puts_noserial(int file, const char *s)
+void console_puts_select(int file, bool serial_only, const char *s)
 {
-   if (!console_dev_is_serial(stdio_devices[file]))
+   if (serial_only == console_dev_is_serial(stdio_devices[file]))
stdio_devices[file]->puts(stdio_devices[file], s);
 }
 
@@ -489,7 +505,7 @@ static void print_pre_console_buffer(int flushpoint)
puts(buf_out);
break;
case PRE_CONSOLE_FLUSHPOINT2_EVERYTHING_BUT_SERIAL:
-   console_puts_noserial(stdout, buf_out);
+   console_puts_select(stdout, false, buf_out);
break;
}
 }
@@ -776,7 +792,7 @@ int console_announce_r(void)
 
display_options_get_banner(false, buf, sizeof(buf));
 
-   console_puts_noserial(stdout, buf);
+   console_puts_select(stdout, false, buf);
 #endif
 
return 0;
diff --git a/include/console.h b/include/console.h
index 74afe22b7e..4c6b8f2614 100644
--- a/include/console.h
+++ b/include/console.h
@@ -7,6 +7,8 @@
 #ifndef __CONSOLE_H
 #define __CONSOLE_H
 
+#include 
+
 extern char console_buffer[];
 
 /* common/console.c */
@@ -72,6 +74,17 @@ int console_record_avail(void);
  */
 int console_announce_r(void);
 
+/**
+ * console_puts_select_stderr() - Output a string to selected console devices
+ *
+ * This writes to stderr only. It is useful for outputting errors
+ *
+ * @serial_only: true to output only to serial, false to output to everything
+ * else
+ * @s: String to output
+ */
+void console_puts_select_stderr(bool serial_only, const char *s);
+
 /*
  * CONSOLE multiplexing.
  */
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 08/26] video: Add a comment for struct video_uc_platdata

2020-05-19 Thread Simon Glass
Add a few notes to explain the purpose of each member of this struct.

Signed-off-by: Simon Glass 
---

 include/video.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/video.h b/include/video.h
index e7c58e86cb..813b5653b0 100644
--- a/include/video.h
+++ b/include/video.h
@@ -19,6 +19,18 @@
 
 struct udevice;
 
+/**
+ * struct video_uc_platdata - uclass platform data for a video device
+ *
+ * This holds information that the uclass needs to know about each device. It
+ * is accessed using dev_get_uclass_platdata(dev). See 'Theory of operation' at
+ * the top of video-uclass.c for details on how this information is set.
+ *
+ * @align: Frame-buffer alignment, indicating the memory boundary the frame
+ * buffer should start on. If 0, 1MB is assumed
+ * @size: Frame-buffer size, in bytes
+ * @base: Base address of frame buffer, 0 if not yet known
+ */
 struct video_uc_platdata {
uint align;
uint size;
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 06/26] video: Adjust rotated console to start at right edge

2020-05-19 Thread Simon Glass
At present when the console is rotated 180 degrees it starts almost a
whole character to the left of the right edge (typically 7 pixels with
an 8-pixel-wide font). On a display which aligns with the font width,
this just wastes space. On a display that does not this can result in
x_frac going negative for the final character (the one on the left
side) and the overflow -EAGAIN check at the start of the function
failing.

Change the function to start at the rightmost pixel to fix these
problems.

Signed-off-by: Simon Glass 
---

 drivers/video/console_rotate.c | 2 +-
 test/dm/video.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c
index 8bb05ae02c..da0ce7b9ce 100644
--- a/drivers/video/console_rotate.c
+++ b/drivers/video/console_rotate.c
@@ -212,7 +212,7 @@ static int console_putc_xy_2(struct udevice *dev, uint 
x_frac, uint y, char ch)
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
linenum = vid_priv->ysize - y - 1;
-   x = vid_priv->xsize - VID_TO_PIXEL(x_frac) - VIDEO_FONT_WIDTH - 1;
+   x = vid_priv->xsize - VID_TO_PIXEL(x_frac) - 1;
line = vid_priv->fb + linenum * vid_priv->line_length + x * pbytes;
 
for (row = 0; row < VIDEO_FONT_HEIGHT; row++) {
diff --git a/test/dm/video.c b/test/dm/video.c
index 0664e3f22b..68f5ba44e7 100644
--- a/test/dm/video.c
+++ b/test/dm/video.c
@@ -251,7 +251,7 @@ DM_TEST(dm_test_video_rotation1, DM_TESTF_SCAN_PDATA | 
DM_TESTF_SCAN_FDT);
 /* Test rotated text output through the console uclass */
 static int dm_test_video_rotation2(struct unit_test_state *uts)
 {
-   ut_assertok(check_vidconsole_output(uts, 2, 785, 446));
+   ut_assertok(check_vidconsole_output(uts, 2, 783, 445));
 
return 0;
 }
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 04/26] sandbox: video: Allow selection of rotated console

2020-05-19 Thread Simon Glass
Add a devicetree property to select a rotated console. This uses the same
encoding as vidconsole itself: 0=normal; 1=90 degrees clockwise, 2=upside
down, 3=90 degrees anticlockwise.

Signed-off-by: Simon Glass 
---

 drivers/video/sandbox_sdl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/sandbox_sdl.c b/drivers/video/sandbox_sdl.c
index 20248e6607..c678e728db 100644
--- a/drivers/video/sandbox_sdl.c
+++ b/drivers/video/sandbox_sdl.c
@@ -53,6 +53,7 @@ static int sandbox_sdl_bind(struct udevice *dev)
plat->xres = dev_read_u32_default(dev, "xres", LCD_MAX_WIDTH);
plat->yres = dev_read_u32_default(dev, "yres", LCD_MAX_HEIGHT);
plat->bpix = dev_read_u32_default(dev, "log2-depth", VIDEO_BPP16);
+   plat->rot = dev_read_u32_default(dev, "rotate", 0);
uc_plat->size = plat->xres * plat->yres * (1 << plat->bpix) / 8;
debug("%s: Frame buffer size %x\n", __func__, uc_plat->size);
 
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 03/26] video: Show an error when a vidconsole function fails

2020-05-19 Thread Simon Glass
At present these functions fail silently even when debugging, which is not
very helpful. Add a way to print a message to the serial output when an
error is detected.

Signed-off-by: Simon Glass 
---

 drivers/video/vidconsole-uclass.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/video/vidconsole-uclass.c 
b/drivers/video/vidconsole-uclass.c
index d30e6db6f6..e06912cf36 100644
--- a/drivers/video/vidconsole-uclass.c
+++ b/drivers/video/vidconsole-uclass.c
@@ -9,12 +9,13 @@
 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include /* Bitmap font for code page 437 */
+#include 
 
 /*
  * Structure to describe a console color
@@ -556,16 +557,31 @@ int vidconsole_put_string(struct udevice *dev, const char 
*str)
 static void vidconsole_putc(struct stdio_dev *sdev, const char ch)
 {
struct udevice *dev = sdev->priv;
+   int ret;
 
-   vidconsole_put_char(dev, ch);
+   ret = vidconsole_put_char(dev, ch);
+   if (ret) {
+#ifdef DEBUG
+   console_puts_select_stderr(true, "[vc err: putc]");
+#endif
+   }
video_sync(dev->parent, false);
 }
 
 static void vidconsole_puts(struct stdio_dev *sdev, const char *s)
 {
struct udevice *dev = sdev->priv;
+   int ret;
+
+   ret = vidconsole_put_string(dev, s);
+   if (ret) {
+#ifdef DEBUG
+   char str[30];
 
-   vidconsole_put_string(dev, s);
+   snprintf(str, sizeof(str), "[vc err: puts %d]", ret);
+   console_puts_select_stderr(true, str);
+#endif
+   }
video_sync(dev->parent, false);
 }
 
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 05/26] video: Split out expression parts into variables

2020-05-19 Thread Simon Glass
The functions in this file do similar things but not always in the same
way. To make the code easier to read and compare, use a separate 'linenum'
variable in every function. This is then multiplied by the line length to
get the offset within the frame buffer to modify. Also use an 'x' variable
to hold the pixel position within that line. This is multipled by the
pixel size and added to the offset.

Also move the pbytes declaration up a little with the other long lines.

A side effect of splitting out these variables is that they are promoted
to int, i.e. a signed type, from the unsigned short used in the
vidconsole_priv struct. This would be necessary should any of the
variables go negative. At present this can actually happen in
console_putc_xy_2(), if the display width is not a multiple of the
character size (see next patch).

Signed-off-by: Simon Glass 
---

 drivers/video/console_rotate.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c
index b485255598..8bb05ae02c 100644
--- a/drivers/video/console_rotate.c
+++ b/drivers/video/console_rotate.c
@@ -59,9 +59,9 @@ static int console_move_rows_1(struct udevice *dev, uint 
rowdst, uint rowsrc,
   uint count)
 {
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
+   int pbytes = VNBYTES(vid_priv->bpix);
void *dst;
void *src;
-   int pbytes = VNBYTES(vid_priv->bpix);
int j;
 
dst = vid_priv->fb + vid_priv->line_length -
@@ -83,14 +83,15 @@ static int console_putc_xy_1(struct udevice *dev, uint 
x_frac, uint y, char ch)
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
struct video_priv *vid_priv = dev_get_uclass_priv(vid);
+   uchar *pfont = video_fontdata + (u8)ch * VIDEO_FONT_HEIGHT;
int pbytes = VNBYTES(vid_priv->bpix);
-   int i, col;
+   int i, col, x, linenum;
int mask = 0x80;
void *line;
-   uchar *pfont = video_fontdata + (u8)ch * VIDEO_FONT_HEIGHT;
 
-   line = vid_priv->fb + (VID_TO_PIXEL(x_frac) + 1) *
-   vid_priv->line_length - (y + 1) * pbytes;
+   linenum = VID_TO_PIXEL(x_frac) + 1;
+   x = y + 1;
+   line = vid_priv->fb + linenum * vid_priv->line_length - x * pbytes;
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
 
@@ -204,16 +205,15 @@ static int console_putc_xy_2(struct udevice *dev, uint 
x_frac, uint y, char ch)
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
struct video_priv *vid_priv = dev_get_uclass_priv(vid);
-   int i, row;
+   int pbytes = VNBYTES(vid_priv->bpix);
+   int i, row, x, linenum;
void *line;
 
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
-
-   line = vid_priv->fb + (vid_priv->ysize - y - 1) *
-   vid_priv->line_length +
-   (vid_priv->xsize - VID_TO_PIXEL(x_frac) -
-   VIDEO_FONT_WIDTH - 1) * VNBYTES(vid_priv->bpix);
+   linenum = vid_priv->ysize - y - 1;
+   x = vid_priv->xsize - VID_TO_PIXEL(x_frac) - VIDEO_FONT_WIDTH - 1;
+   line = vid_priv->fb + linenum * vid_priv->line_length + x * pbytes;
 
for (row = 0; row < VIDEO_FONT_HEIGHT; row++) {
unsigned int idx = (u8)ch * VIDEO_FONT_HEIGHT + row;
@@ -312,9 +312,9 @@ static int console_move_rows_3(struct udevice *dev, uint 
rowdst, uint rowsrc,
   uint count)
 {
struct video_priv *vid_priv = dev_get_uclass_priv(dev->parent);
+   int pbytes = VNBYTES(vid_priv->bpix);
void *dst;
void *src;
-   int pbytes = VNBYTES(vid_priv->bpix);
int j;
 
dst = vid_priv->fb + rowdst * VIDEO_FONT_HEIGHT * pbytes;
@@ -334,16 +334,16 @@ static int console_putc_xy_3(struct udevice *dev, uint 
x_frac, uint y, char ch)
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
struct video_priv *vid_priv = dev_get_uclass_priv(vid);
+   uchar *pfont = video_fontdata + (u8)ch * VIDEO_FONT_HEIGHT;
int pbytes = VNBYTES(vid_priv->bpix);
-   int i, col;
+   int i, col, x;
int mask = 0x80;
-   void *line = vid_priv->fb +
-   (vid_priv->ysize - VID_TO_PIXEL(x_frac) - 1) *
-   vid_priv->line_length + y * pbytes;
-   uchar *pfont = video_fontdata + (u8)ch * VIDEO_FONT_HEIGHT;
+   void *line;
 
if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
+   x = vid_priv->ysize - VID_TO_PIXEL(x_frac) - 1;
+   line = vid_priv->fb + x * vid_priv->line_length + y * pbytes;
 
for (col = 0; col 

Re: U-Boot DM device tree and Linux device tree - what are the differences and why?

2020-05-19 Thread Rudolf J Streif
Hi Fabio

On 5/19/20 5:23 AM, Fabio Estevam wrote:
> Hi Rudolf,
>
> On Tue, May 19, 2020 at 1:28 AM Rudolf J Streif
>  wrote:
>> I solved the problem with u-boot not recognizing the eMMC. The device
>> tree is working now for u-boot.
>>
>> However, i.MX6 is using SPL which is loaded into OCRAM. If I flash SPL
>> and u-boot to a boot partition on the eMMC the boot ROM loads SPL just
>> fine but then SPL cannot load u-boot from eMMC:
>>
>> Trying to boot from MMC1
>> MMC: no card present
>> spl: mmc init failed with error: -123
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
>>
>> If I enable CONFIG_SPL_DM=y and CONFIG_SPL_DM_MMC=y then I am getting
>> this undefined reference (and a whole slew of other related to DM):
>>
>> common/built-in.o:(.u_boot_list_2_uclass_2_usb_hub+0x8): undefined
>> reference to `dm_scan_fdt_dev'
>>
>> Even if I get this to link then the next question of course is if it
>> will fit into the 68k OCRAM that the SoC has (the whole device tree
>> infrastructure has a rather large footprint). It is hard to follow why
>> the DM now is essentially enforced for storage media but does not seem
>> to be tested with SPL.
> I had a similar issue on a pico-imx6ul board. I preferred to put the
> MMC initialization code in SPL rather than relying on DM as in SPL we
> are very tight in memory.
>
> Please see this commit:
> https://gitlab.denx.de/u-boot/u-boot/-/commit/9b8d9ec41a6f161d53d32bf71f79332236b44ba1

Thank you so much. You pointed me into the right direction. I was able
to find a solution for my board.

Much appreciated.

Rudi

-- 
-
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700




signature.asc
Description: OpenPGP digital signature


[PATCH 01/26] x86: fsp: Reinit the FPU after FSP meminit

2020-05-19 Thread Simon Glass
The APL FSP appears to leave the FPU in a bad state in that it has
registers in use. This causes an error when the next FPU operation is
performed.

Work around this by re-resetting the FPU after calling FSP-M. This allows
the freetype console to work correctly.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/i386/cpu.c   | 5 +
 arch/x86/include/asm/u-boot-x86.h | 8 
 arch/x86/lib/fsp2/fsp_meminit.c   | 1 +
 3 files changed, 14 insertions(+)

diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index 435e50edad..d27324cb4e 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -363,6 +363,11 @@ static void setup_cpu_features(void)
: : "i" (em_rst), "i" (mp_ne_set) : "eax");
 }
 
+void cpu_reinit_fpu(void)
+{
+   asm ("fninit\n");
+}
+
 static void setup_identity(void)
 {
/* identify CPU via cpuid and store the decoded info into gd->arch */
diff --git a/arch/x86/include/asm/u-boot-x86.h 
b/arch/x86/include/asm/u-boot-x86.h
index 3e5d56d075..bd3f44014c 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -43,6 +43,14 @@ int x86_cpu_reinit_f(void);
  */
 int x86_cpu_init_tpl(void);
 
+/**
+ * cpu_reinit_fpu() - Reinit the FPU if something is wrong with it
+ *
+ * The FSP-M code can leave registers in use in the FPU. This functions reinits
+ * it so that the FPU can be used safely
+ */
+void cpu_reinit_fpu(void);
+
 int cpu_init_f(void);
 void setup_gdt(struct global_data *id, u64 *gdt_addr);
 /*
diff --git a/arch/x86/lib/fsp2/fsp_meminit.c b/arch/x86/lib/fsp2/fsp_meminit.c
index 1a758147b0..faf9c29aef 100644
--- a/arch/x86/lib/fsp2/fsp_meminit.c
+++ b/arch/x86/lib/fsp2/fsp_meminit.c
@@ -85,6 +85,7 @@ int fsp_memory_init(bool s3wake, bool use_spi_flash)
func = (fsp_memory_init_func)(hdr->img_base + hdr->fsp_mem_init);
ret = func(, );
bootstage_accum(BOOTSTAGE_ID_ACCUM_FSP_M);
+   cpu_reinit_fpu();
if (ret)
return log_msg_ret("SDRAM init fail\n", ret);
 
-- 
2.26.2.761.g0e0b3e54be-goog



[PATCH 00/26] x86: video: Speed up the framebuffer

2020-05-19 Thread Simon Glass
Some architectures use a cached framebuffer and flush the cache as needed
so that changes are visible. This is supported by U-Boot.

However x86 uses an uncached framebuffer with a 'write-combining' feature
to speed up writes. Reads are permitted but they are extremely expensive.

Unfortunately, reading from the frame buffer is quite common, e.g. to
scroll it. This makes scrolling very slow.

This series adds a new feature which supports copying modified parts of
the frame buffer to the uncached hardware buffer. This speeds up scrolling
dramatically on x86 so the extra complexity cost seems worth it.

In an extreme case, the time to print the environment on minnowboard with
1280x1024 and CONFIG_CONSOLE_SCROLL_LINES disabled is reduced
significantly, from 13 seconds to 300ms.


Simon Glass (26):
  x86: fsp: Reinit the FPU after FSP meminit
  console: Add a way to output to serial only
  video: Show an error when a vidconsole function fails
  sandbox: video: Allow selection of rotated console
  video: Split out expression parts into variables
  video: Adjust rotated console to start at right edge
  video: Drop unnecessary #ifdef around vid_console_color()
  video: Add a comment for struct video_uc_platdata
  video: Add support for copying to a hardware framebuffer
  video: Set up the copy framebuffer when enabled
  video: Clear the copy framebuffer when clearing the screen
  video: Add helpers for vidconsole for the copy framebuffer
  video: Update normal console to support copy buffer
  video: Update truetype console to support copy buffer
  video: Update rotated console to support copy buffer
  video: Update the copy framebuffer when writing bitmaps
  video: Add comments to struct sandbox_sdl_plat
  video: sandbox: Add support for the copy framebuffer
  video: pci: Set up the copy framebuffer
  x86: fsp: video: Allocate a frame buffer when needed
  video: Correctly handle multiple framebuffers
  x86: video: Support copy framebuffer with probed devices
  x86: chromebook_samus: Enable the copy framebuffer
  x86: chromebook_link: Enable the copy framebuffer
  x86: minnowmax: Enable the copy framebuffer
  x86: minnowmax: Drop screen resolution to 1024x768

 arch/x86/cpu/i386/cpu.c|   5 ++
 arch/x86/include/asm/u-boot-x86.h  |   8 +++
 arch/x86/lib/fsp/fsp_graphics.c|  12 
 arch/x86/lib/fsp2/fsp_meminit.c|   1 +
 common/console.c   |  28 ++--
 configs/chromebook_link_defconfig  |   2 +-
 configs/chromebook_samus_defconfig |   2 +-
 configs/minnowmax_defconfig|   4 +-
 configs/sandbox_defconfig  |   1 +
 drivers/pci/pci_rom.c  |  22 +-
 drivers/video/Kconfig  |  31 +
 drivers/video/broadwell_igd.c  |  16 -
 drivers/video/console_normal.c |  26 +++-
 drivers/video/console_rotate.c | 103 -
 drivers/video/console_truetype.c   |  43 
 drivers/video/ivybridge_igd.c  |  26 ++--
 drivers/video/sandbox_sdl.c|  10 ++-
 drivers/video/vesa.c   |  30 -
 drivers/video/vidconsole-uclass.c  |  44 +++-
 drivers/video/video-uclass.c   |  93 +-
 drivers/video/video_bmp.c  |  16 -
 include/console.h  |  13 
 include/dm/test.h  |  14 +++-
 include/video.h|  41 
 include/video_console.h|  51 +-
 test/dm/video.c|  60 ++---
 26 files changed, 600 insertions(+), 102 deletions(-)

-- 
2.26.2.761.g0e0b3e54be-goog



Re: [PATCH v2 1/2] spi: call WATCHDOG_RESET() in spi_nor_wait_till_ready_with_timeout()

2020-05-19 Thread Rasmus Villemoes
On 20/03/2020 11.14, Rasmus Villemoes wrote:
> I have a board for which doing "sf erase 0x10 0x8"
> consistently causes the external watchdog circuit to reset the
> board. Make sure to pet the watchdog during slow operations such as
> erasing or writing large areas of a spi nor flash.

Ping.


Re: [PATCH 2/2] thermal: imx_scu_thermal: fix getting DT alert property value

2020-05-19 Thread Anatolij Gustschin
On Tue, 19 May 2020 11:45:55 +
Peng Fan peng@nxp.com wrote:
...
> Do you have more insights about uclass_get_device and 
> uclass_get_device_byname?
> uclass_get_device not work, but uclass_get_device_byname work.

well, we have three thermal uclass devices on i.MX8QXP:
 thermal   0  [   ]   imx_sc_thermal|-- thermal-sensor
 thermal   1  [   ]   imx_sc_thermal|   |-- cpu-thermal0
 thermal   2  [   ]   imx_sc_thermal|   `-- drc-thermal0

when using uclass_get_device(UCLASS_THERMAL, 0, _dev), the
first device ("thermal-sensor") is matching and for this device
imx_sc_thermal_ofdata_to_platdata() will be called, it then tries to
get the "thermal-sensors" list in the node of "thermal-sensor" device
(dev_of_offset(dev)), but this is wrong, since this list is a property
of the "cpu-thermal0" node according to bindings.

Therefore ofdata_to_platdata() can't find the "thermal-sensors" list
and does not initialize alert/critical pdata values.

When uclass_get_device_by_name() is used, then 
imx_sc_thermal_ofdata_to_platdata()
is called for "cpu-thermal0" device, here getting the list works
and alert/critical pdata values are initialized properly.

--
Anatolij


[PATCH v2 10/10] test: dm: rtc: add tests of rtc shell command

2020-05-19 Thread Rasmus Villemoes
Signed-off-by: Rasmus Villemoes 
---
 test/dm/rtc.c | 61 +++
 1 file changed, 61 insertions(+)

diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index 5301805d19..d1d8ff0375 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -174,6 +175,66 @@ static int dm_test_rtc_read_write(struct unit_test_state 
*uts)
 }
 DM_TEST(dm_test_rtc_read_write, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
 
+/* Test 'rtc list' command */
+static int dm_test_rtc_cmd_list(struct unit_test_state *uts)
+{
+   console_record_reset();
+
+   run_command("rtc list", 0);
+   ut_assert_nextline("RTC #0 - rtc@43");
+   ut_assert_nextline("RTC #1 - rtc@61");
+   ut_assert_console_end();
+
+   return 0;
+}
+DM_TEST(dm_test_rtc_cmd_list, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+/* Test 'rtc read' and 'rtc write' commands */
+static int dm_test_rtc_cmd_rw(struct unit_test_state *uts)
+{
+   console_record_reset();
+
+   run_command("rtc dev 0", 0);
+   ut_assert_nextline("RTC #0 - rtc@43");
+   ut_assert_console_end();
+
+   run_command("rtc write 0x30 aabb", 0);
+   ut_assert_console_end();
+
+   run_command("rtc read 0x30 2", 0);
+   ut_assert_nextline("48: 0xaa");
+   ut_assert_nextline("49: 0xbb");
+   ut_assert_console_end();
+
+   run_command("rtc dev 1", 0);
+   ut_assert_nextline("RTC #1 - rtc@61");
+   ut_assert_console_end();
+
+   run_command("rtc write 0x30 ccdd", 0);
+   ut_assert_console_end();
+
+   run_command("rtc read 0x30 2", 0);
+   ut_assert_nextline("48: 0xcc");
+   ut_assert_nextline("49: 0xdd");
+   ut_assert_console_end();
+
+   /*
+* Switch back to device #0, check that its aux registers
+* still have the same values.
+*/
+   run_command("rtc dev 0", 0);
+   ut_assert_nextline("RTC #0 - rtc@43");
+   ut_assert_console_end();
+
+   run_command("rtc read 0x30 2", 0);
+   ut_assert_nextline("48: 0xaa");
+   ut_assert_nextline("49: 0xbb");
+   ut_assert_console_end();
+
+   return 0;
+}
+DM_TEST(dm_test_rtc_cmd_rw, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
 /* Reset the time */
 static int dm_test_rtc_reset(struct unit_test_state *uts)
 {
-- 
2.23.0



[PATCH v2 07/10] rtc: sandbox-rtc: fix set method

2020-05-19 Thread Rasmus Villemoes
The current set method is broken; a simple test case is to first set
the date to something in April, then change the date to 31st May:

=> date 040412122020.34
Date: 2020-04-04 (Saturday)Time: 12:12:34
=> date 053112122020.34
Date: 2020-05-01 (Friday)Time: 12:12:34

or via the amending of the existing rtc_set_get test case similarly:

$ ./u-boot -T -v
=> ut dm rtc_set_get
Test: dm_test_rtc_set_get: rtc.c
expected: 31/08/2004 18:18:00
actual: 01/08/2004 18:18:00

The problem is that after each register write,
sandbox_i2c_rtc_complete_write() gets called and sets the internal
time from the current set of registers. However, when we get to
writing 31 to mday, the registers are in an inconsistent state (mon is
still 4), so the mktime machinery ends up translating April 31st to
May 1st. Upon the next register write, the registers are populated by
sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets
overwritten by a 1.

Fix it by writing all registers at once, and for consistency, update
the get method to retrieve them all with one "i2c transfer".

Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/sandbox_rtc.c | 65 +++
 test/dm/rtc.c | 15 -
 2 files changed, 38 insertions(+), 42 deletions(-)

diff --git a/drivers/rtc/sandbox_rtc.c b/drivers/rtc/sandbox_rtc.c
index b08d758a74..77065e49c7 100644
--- a/drivers/rtc/sandbox_rtc.c
+++ b/drivers/rtc/sandbox_rtc.c
@@ -14,55 +14,38 @@
 
 static int sandbox_rtc_get(struct udevice *dev, struct rtc_time *time)
 {
-   time->tm_sec = dm_i2c_reg_read(dev, REG_SEC);
-   if (time->tm_sec < 0)
-   return time->tm_sec;
-   time->tm_min = dm_i2c_reg_read(dev, REG_MIN);
-   if (time->tm_min < 0)
-   return time->tm_min;
-   time->tm_hour = dm_i2c_reg_read(dev, REG_HOUR);
-   if (time->tm_hour < 0)
-   return time->tm_hour;
-   time->tm_mday = dm_i2c_reg_read(dev, REG_MDAY);
-   if (time->tm_mday < 0)
-   return time->tm_mday;
-   time->tm_mon = dm_i2c_reg_read(dev, REG_MON);
-   if (time->tm_mon < 0)
-   return time->tm_mon;
-   time->tm_year = dm_i2c_reg_read(dev, REG_YEAR);
-   if (time->tm_year < 0)
-   return time->tm_year;
-   time->tm_year += 1900;
-   time->tm_wday = dm_i2c_reg_read(dev, REG_WDAY);
-   if (time->tm_wday < 0)
-   return time->tm_wday;
+   u8 buf[7];
+   int ret;
+
+   ret = dm_i2c_read(dev, REG_SEC, buf, sizeof(buf));
+   if (ret < 0)
+   return ret;
+
+   time->tm_sec  = buf[REG_SEC - REG_SEC];
+   time->tm_min  = buf[REG_MIN - REG_SEC];
+   time->tm_hour = buf[REG_HOUR - REG_SEC];
+   time->tm_mday = buf[REG_MDAY - REG_SEC];
+   time->tm_mon  = buf[REG_MON - REG_SEC];
+   time->tm_year = buf[REG_YEAR - REG_SEC] + 1900;
+   time->tm_wday = buf[REG_WDAY - REG_SEC];
 
return 0;
 }
 
 static int sandbox_rtc_set(struct udevice *dev, const struct rtc_time *time)
 {
+   u8 buf[7];
int ret;
 
-   ret = dm_i2c_reg_write(dev, REG_SEC, time->tm_sec);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_MIN, time->tm_min);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_HOUR, time->tm_hour);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_MDAY, time->tm_mday);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_MON, time->tm_mon);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_YEAR, time->tm_year - 1900);
-   if (ret < 0)
-   return ret;
-   ret = dm_i2c_reg_write(dev, REG_WDAY, time->tm_wday);
+   buf[REG_SEC - REG_SEC]  = time->tm_sec;
+   buf[REG_MIN - REG_SEC]  = time->tm_min;
+   buf[REG_HOUR - REG_SEC] = time->tm_hour;
+   buf[REG_MDAY - REG_SEC] = time->tm_mday;
+   buf[REG_MON  - REG_SEC] = time->tm_mon;
+   buf[REG_YEAR - REG_SEC] = time->tm_year - 1900;
+   buf[REG_WDAY - REG_SEC] = time->tm_wday;
+
+   ret = dm_i2c_write(dev, REG_SEC, buf, sizeof(buf));
if (ret < 0)
return ret;
 
diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index 7188742764..e5454139cd 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -69,7 +69,20 @@ static int dm_test_rtc_set_get(struct unit_test_state *uts)
old_base_time = sandbox_i2c_rtc_get_set_base_time(emul, -1);
 
memset(, '\0', sizeof(time));
-   time.tm_mday = 25;
+   time.tm_mday = 3;
+   time.tm_mon = 6;
+   time.tm_year = 2004;
+   time.tm_sec = 0;
+   time.tm_min = 18;
+   time.tm_hour = 18;
+   ut_assertok(dm_rtc_set(dev, ));
+
+   memset(, '\0', sizeof(cmp));
+   ut_assertok(dm_rtc_get(dev, ));
+   ut_assertok(cmp_times(, , true));
+
+   memset(, '\0', sizeof(time));
+   time.tm_mday = 31;
  

[PATCH v2 09/10] test: dm: rtc: add test of rtc_read, rtc_write

2020-05-19 Thread Rasmus Villemoes
Define a few aux registers and check that they can be read/written
individually. Also check that one can access the time-keeping
registers directly and get the expected results.

Signed-off-by: Rasmus Villemoes 
---
 arch/sandbox/include/asm/rtc.h |  5 
 test/dm/rtc.c  | 45 ++
 2 files changed, 50 insertions(+)

diff --git a/arch/sandbox/include/asm/rtc.h b/arch/sandbox/include/asm/rtc.h
index 1fbfea7999..5bb032f59f 100644
--- a/arch/sandbox/include/asm/rtc.h
+++ b/arch/sandbox/include/asm/rtc.h
@@ -21,6 +21,11 @@ enum {
 
REG_RESET   = 0x20,
 
+   REG_AUX0= 0x30,
+   REG_AUX1,
+   REG_AUX2,
+   REG_AUX3,
+
REG_COUNT   = 0x80,
 };
 
diff --git a/test/dm/rtc.c b/test/dm/rtc.c
index e5454139cd..5301805d19 100644
--- a/test/dm/rtc.c
+++ b/test/dm/rtc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -129,6 +130,50 @@ static int dm_test_rtc_set_get(struct unit_test_state *uts)
 }
 DM_TEST(dm_test_rtc_set_get, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
 
+static int dm_test_rtc_read_write(struct unit_test_state *uts)
+{
+   struct rtc_time time;
+   struct udevice *dev, *emul;
+   long old_offset;
+   u8 buf[4], reg;
+
+   ut_assertok(uclass_get_device(UCLASS_RTC, 0, ));
+
+   memcpy(buf, "car", 4);
+   ut_assertok(rtc_write(dev, REG_AUX0, buf, 4));
+   memset(buf, '\0', sizeof(buf));
+   ut_assertok(rtc_read(dev, REG_AUX0, buf, 4));
+   ut_asserteq(memcmp(buf, "car", 4), 0);
+
+   reg = 'b';
+   ut_assertok(rtc_write(dev, REG_AUX0, , 1));
+   memset(buf, '\0', sizeof(buf));
+   ut_assertok(rtc_read(dev, REG_AUX0, buf, 4));
+   ut_asserteq(memcmp(buf, "bar", 4), 0);
+
+   reg = 't';
+   ut_assertok(rtc_write(dev, REG_AUX2, , 1));
+   memset(buf, '\0', sizeof(buf));
+   ut_assertok(rtc_read(dev, REG_AUX1, buf, 3));
+   ut_asserteq(memcmp(buf, "at", 3), 0);
+
+   ut_assertok(i2c_emul_find(dev, ));
+   ut_assert(emul != NULL);
+
+   old_offset = sandbox_i2c_rtc_set_offset(emul, false, 0);
+   ut_assertok(dm_rtc_get(dev, ));
+
+   ut_assertok(rtc_read(dev, REG_SEC, , 1));
+   ut_asserteq(time.tm_sec, reg);
+   ut_assertok(rtc_read(dev, REG_MDAY, , 1));
+   ut_asserteq(time.tm_mday, reg);
+
+   sandbox_i2c_rtc_set_offset(emul, true, old_offset);
+
+   return 0;
+}
+DM_TEST(dm_test_rtc_read_write, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
 /* Reset the time */
 static int dm_test_rtc_reset(struct unit_test_state *uts)
 {
-- 
2.23.0



[PATCH v2 08/10] rtc: i2c_rtc_emul: catch any write to the "reset" register

2020-05-19 Thread Rasmus Villemoes
It's more natural that any write that happens to touch the reset
register should cause a reset, rather than just a write that starts at
that offset.

Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/i2c_rtc_emul.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/i2c_rtc_emul.c b/drivers/rtc/i2c_rtc_emul.c
index d4b33e59d6..3a7f1fe53e 100644
--- a/drivers/rtc/i2c_rtc_emul.c
+++ b/drivers/rtc/i2c_rtc_emul.c
@@ -196,7 +196,8 @@ static int sandbox_i2c_rtc_xfer(struct udevice *emul, 
struct i2c_msg *msg,
 
/* Write the register */
memcpy(plat->reg + offset, ptr, len);
-   if (offset == REG_RESET)
+   /* If the reset register was written to, do reset. */
+   if (offset <= REG_RESET && REG_RESET < offset + len)
reset_time(emul);
}
}
-- 
2.23.0



[PATCH v2 01/10] rtc: add rtc_read helper and ->read method

2020-05-19 Thread Rasmus Villemoes
Some users may want to read multiple consecutive 8-bit
registers. Instead of each caller having to implement the loop,
provide a rtc_read() helper. Also, allow a driver to provide a ->read
method, which can be more efficient than reading one register at a
time.

Reviewed-by: Simon Glass 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/rtc-uclass.c | 18 ++
 include/rtc.h| 23 +++
 2 files changed, 41 insertions(+)

diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
index a0a238aedd..44d76bb70f 100644
--- a/drivers/rtc/rtc-uclass.c
+++ b/drivers/rtc/rtc-uclass.c
@@ -39,6 +39,24 @@ int dm_rtc_reset(struct udevice *dev)
return ops->reset(dev);
 }
 
+int rtc_read(struct udevice *dev, unsigned int reg, u8 *buf, unsigned int len)
+{
+   struct rtc_ops *ops = rtc_get_ops(dev);
+
+   assert(ops);
+   if (ops->read)
+   return ops->read(dev, reg, buf, len);
+   if (!ops->read8)
+   return -ENOSYS;
+   while (len--) {
+   int ret = ops->read8(dev, reg++);
+   if (ret < 0)
+   return ret;
+   *buf++ = ret;
+   }
+   return 0;
+}
+
 int rtc_read8(struct udevice *dev, unsigned int reg)
 {
struct rtc_ops *ops = rtc_get_ops(dev);
diff --git a/include/rtc.h b/include/rtc.h
index 8aabfc1162..1c9c09fef8 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -55,6 +55,18 @@ struct rtc_ops {
 */
int (*reset)(struct udevice *dev);
 
+   /**
+* read() - Read multiple 8-bit registers
+*
+* @dev:Device to read from
+* @reg:First register to read
+* @buf:Output buffer
+* @len:Number of registers to read
+* @return 0 if OK, -ve on error
+*/
+   int (*read)(struct udevice *dev, unsigned int reg,
+  u8 *buf, unsigned int len);
+
/**
 * read8() - Read an 8-bit register
 *
@@ -109,6 +121,17 @@ int dm_rtc_set(struct udevice *dev, struct rtc_time *time);
  */
 int dm_rtc_reset(struct udevice *dev);
 
+/**
+ * rtc_read() - Read multiple 8-bit registers
+ *
+ * @dev:   Device to read from
+ * @reg:   First register to read
+ * @buf:   Output buffer
+ * @len:   Number of registers to read
+ * @return 0 if OK, -ve on error
+ */
+int rtc_read(struct udevice *dev, unsigned int reg, u8 *buf, unsigned int len);
+
 /**
  * rtc_read8() - Read an 8-bit register
  *
-- 
2.23.0



[PATCH v2 05/10] rtc: pcf2127: provide ->write method

2020-05-19 Thread Rasmus Villemoes
Reviewed-by: Simon Glass 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/pcf2127.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index f48cd8cb18..a3faf62ee0 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -42,6 +42,12 @@ static int pcf2127_rtc_read(struct udevice *dev, uint 
offset, u8 *buffer, uint l
return dm_i2c_xfer(dev, , 1);
 }
 
+static int pcf2127_rtc_write(struct udevice *dev, uint offset,
+const u8 *buffer, uint len)
+{
+   return dm_i2c_write(dev, offset, buffer, len);
+}
+
 static int pcf2127_rtc_set(struct udevice *dev, const struct rtc_time *tm)
 {
uchar buf[7] = {0};
@@ -109,6 +115,7 @@ static const struct rtc_ops pcf2127_rtc_ops = {
.set = pcf2127_rtc_set,
.reset = pcf2127_rtc_reset,
.read = pcf2127_rtc_read,
+   .write = pcf2127_rtc_write,
 };
 
 static const struct udevice_id pcf2127_rtc_ids[] = {
-- 
2.23.0



[PATCH v2 06/10] rtc: add rtc command

2020-05-19 Thread Rasmus Villemoes
Mostly as an aid for debugging RTC drivers, provide a command that can
be used to read/write arbitrary registers (assuming the driver
provides the read/write methods or their single-register-at-a-time
variants).

Signed-off-by: Rasmus Villemoes 
---
 cmd/Kconfig  |   6 ++
 cmd/Makefile |   1 +
 cmd/rtc.c| 159 +++
 3 files changed, 166 insertions(+)
 create mode 100644 cmd/rtc.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index f9be1988f6..7eea25facd 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1715,6 +1715,12 @@ config CMD_DATE
  Enable the 'date' command for getting/setting the time/date in RTC
  devices.
 
+config CMD_RTC
+   bool "rtc"
+   depends on DM_RTC
+   help
+ Enable the 'rtc' command for low-level access to RTC devices.
+
 config CMD_TIME
bool "time"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 974ad48b0a..c7992113e4 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_CMD_REISER) += reiser.o
 obj-$(CONFIG_CMD_REMOTEPROC) += remoteproc.o
 obj-$(CONFIG_CMD_RNG) += rng.o
 obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
+obj-$(CONFIG_CMD_RTC) += rtc.o
 obj-$(CONFIG_SANDBOX) += host.o
 obj-$(CONFIG_CMD_SATA) += sata.o
 obj-$(CONFIG_CMD_NVME) += nvme.o
diff --git a/cmd/rtc.c b/cmd/rtc.c
new file mode 100644
index 00..e26b7ca18f
--- /dev/null
+++ b/cmd/rtc.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_RTC_BYTES 32
+
+static int do_rtc_read(struct udevice *dev, int argc, char * const argv[])
+{
+   u8 buf[MAX_RTC_BYTES];
+   int reg, len, ret;
+   u8 *addr;
+
+   if (argc < 2 || argc > 3)
+   return CMD_RET_USAGE;
+
+   reg = simple_strtoul(argv[0], NULL, 0);
+   len = simple_strtoul(argv[1], NULL, 0);
+   if (argc == 3) {
+   addr = map_sysmem(simple_strtoul(argv[2], NULL, 16), len);
+   } else {
+   if (len > sizeof(buf)) {
+   printf("can read at most %d registers at a time\n", 
MAX_RTC_BYTES);
+   return CMD_RET_FAILURE;
+   }
+   addr = buf;
+   }
+
+   ret = rtc_read(dev, reg, addr, len);
+   if (ret) {
+   printf("rtc_read() failed: %d\n", ret);
+   ret = CMD_RET_FAILURE;
+   goto out;
+   } else {
+   ret = CMD_RET_SUCCESS;
+   }
+
+   if (argc == 2) {
+   while (len--)
+   printf("%d: 0x%02x\n", reg++, *addr++);
+   }
+out:
+   if (argc == 3)
+   unmap_sysmem(addr);
+   return ret;
+}
+
+static int do_rtc_write(struct udevice *dev, int argc, char * const argv[])
+{
+   u8 buf[MAX_RTC_BYTES];
+   u8 *addr;
+   int reg, len, ret;
+
+   if (argc < 2 || argc > 3)
+   return CMD_RET_USAGE;
+
+   reg = simple_strtoul(argv[0], NULL, 0);
+
+   if (argc == 3) {
+   len = simple_strtoul(argv[1], NULL, 0);
+   addr = map_sysmem(simple_strtoul(argv[2], NULL, 16), len);
+   } else {
+   const char *s = argv[1];
+
+   /* Convert hexstring, bail out if too long. */
+   addr = buf;
+   len = strlen(s);
+   if (len > 2*MAX_RTC_BYTES) {
+   printf("hex string too long, can write at most %d 
bytes\n", MAX_RTC_BYTES);
+   return CMD_RET_FAILURE;
+   }
+   len /= 2;
+   if (hex2bin(addr, s, len)) {
+   printf("invalid hex string\n");
+   return CMD_RET_FAILURE;
+   }
+   }
+
+   ret = rtc_write(dev, reg, addr, len);
+   if (ret) {
+   printf("rtc_write() failed: %d\n", ret);
+   ret = CMD_RET_FAILURE;
+   } else {
+   ret = CMD_RET_SUCCESS;
+   }
+
+   if (argc == 3)
+   unmap_sysmem(addr);
+   return ret;
+}
+
+int do_rtc(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   static int curr_rtc = 0;
+   struct udevice *dev;
+   int ret, idx;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   argc--;
+   argv++;
+
+   if (!strcmp(argv[0], "list")) {
+   struct uclass *uc;
+   idx = 0;
+
+   uclass_id_foreach_dev(UCLASS_RTC, dev, uc) {
+   printf("RTC #%d - %s\n", idx++, dev->name);
+   }
+   if (!idx) {
+   printf("*** no RTC devices available ***\n");
+   return CMD_RET_FAILURE;
+   }
+   return CMD_RET_SUCCESS;
+   }
+
+   idx = curr_rtc;
+   if (!strcmp(argv[0], "dev") && argc >= 2)
+   idx = simple_strtoul(argv[1], NULL, 10);
+
+   ret = uclass_get_device(UCLASS_RTC, idx, );
+ 

[PATCH v2 03/10] rtc: fall back to ->{read, write} if ->{read, write}8 are not provided

2020-05-19 Thread Rasmus Villemoes
Similar to how the rtc_{read,write} functions fall back to
using the {read,write}8 methods, do the opposite in the
rtc_{read,write}8 functions.

This way, each driver only needs to provide either ->read8 or ->read
to make both rtc_read8() and rtc_read() work - without this, a driver
that provides ->read() would most likely just duplicate the logic here
for implementing a ->read8() method in term of its ->read()
method. The same remarks of course apply to the write case.

Reviewed-by: Simon Glass 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/rtc-uclass.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
index cc5f9c7baa..3cdeb89084 100644
--- a/drivers/rtc/rtc-uclass.c
+++ b/drivers/rtc/rtc-uclass.c
@@ -80,9 +80,17 @@ int rtc_read8(struct udevice *dev, unsigned int reg)
struct rtc_ops *ops = rtc_get_ops(dev);
 
assert(ops);
-   if (!ops->read8)
-   return -ENOSYS;
-   return ops->read8(dev, reg);
+   if (ops->read8)
+   return ops->read8(dev, reg);
+   if (ops->read) {
+   u8 buf[1];
+   int ret = ops->read(dev, reg, buf, 1);
+
+   if (ret < 0)
+   return ret;
+   return buf[0];
+   }
+   return -ENOSYS;
 }
 
 int rtc_write8(struct udevice *dev, unsigned int reg, int val)
@@ -90,9 +98,13 @@ int rtc_write8(struct udevice *dev, unsigned int reg, int 
val)
struct rtc_ops *ops = rtc_get_ops(dev);
 
assert(ops);
-   if (!ops->write8)
-   return -ENOSYS;
-   return ops->write8(dev, reg, val);
+   if (ops->write8)
+   return ops->write8(dev, reg, val);
+   if (ops->write) {
+   u8 buf[1] = { val };
+   return ops->write(dev, reg, buf, 1);
+   }
+   return -ENOSYS;
 }
 
 int rtc_read16(struct udevice *dev, unsigned int reg, u16 *valuep)
-- 
2.23.0



[PATCH v2 02/10] rtc: add rtc_write() helper

2020-05-19 Thread Rasmus Villemoes
Similar to rtc_read(), introduce a helper that allows the caller to
write multiple consecutive 8-bit registers with one call. If the
driver provides the ->write method, use that, otherwise loop using
->write8.

Reviewed-by: Simon Glass 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/rtc-uclass.c | 18 ++
 include/rtc.h| 24 
 2 files changed, 42 insertions(+)

diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
index 44d76bb70f..cc5f9c7baa 100644
--- a/drivers/rtc/rtc-uclass.c
+++ b/drivers/rtc/rtc-uclass.c
@@ -57,6 +57,24 @@ int rtc_read(struct udevice *dev, unsigned int reg, u8 *buf, 
unsigned int len)
return 0;
 }
 
+int rtc_write(struct udevice *dev, unsigned int reg,
+ const u8 *buf, unsigned int len)
+{
+   struct rtc_ops *ops = rtc_get_ops(dev);
+
+   assert(ops);
+   if (ops->write)
+   return ops->write(dev, reg, buf, len);
+   if (!ops->write8)
+   return -ENOSYS;
+   while (len--) {
+   int ret = ops->write8(dev, reg++, *buf++);
+   if (ret < 0)
+   return ret;
+   }
+   return 0;
+}
+
 int rtc_read8(struct udevice *dev, unsigned int reg)
 {
struct rtc_ops *ops = rtc_get_ops(dev);
diff --git a/include/rtc.h b/include/rtc.h
index 1c9c09fef8..8c66d37703 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -67,6 +67,18 @@ struct rtc_ops {
int (*read)(struct udevice *dev, unsigned int reg,
   u8 *buf, unsigned int len);
 
+   /**
+* write() - Write multiple 8-bit registers
+*
+* @dev:Device to write to
+* @reg:First register to write
+* @buf:Input buffer
+* @len:Number of registers to write
+* @return 0 if OK, -ve on error
+*/
+   int (*write)(struct udevice *dev, unsigned int reg,
+const u8 *buf, unsigned int len);
+
/**
 * read8() - Read an 8-bit register
 *
@@ -132,6 +144,18 @@ int dm_rtc_reset(struct udevice *dev);
  */
 int rtc_read(struct udevice *dev, unsigned int reg, u8 *buf, unsigned int len);
 
+/**
+ * rtc_write() - Write multiple 8-bit registers
+ *
+ * @dev:   Device to write to
+ * @reg:   First register to write
+ * @buf:   Input buffer
+ * @len:   Number of registers to write
+ * @return 0 if OK, -ve on error
+ */
+int rtc_write(struct udevice *dev, unsigned int reg,
+ const u8 *buf, unsigned int len);
+
 /**
  * rtc_read8() - Read an 8-bit register
  *
-- 
2.23.0



[PATCH v2 00/10] new rtc methods, rtc command, and tests

2020-05-19 Thread Rasmus Villemoes
I need access to registers other than just the timekeeping ones of the
pcf2127, so I wanted to implement ->read8 and ->write8. But for
testing these it appeared there was no convenient way to invoke those
from the shell, so I also ended up adding such a command.

Also, it seemed more natural to provide array variants that can read
or write several registers at once, so rtc_ops is expanded a bit.

Changes in v2:

- Use simply "read" and "write" instead of "read8_array",
  "write8_array", both for functions and methods, as suggested by
  Simon.

- The rtc command's interface has been simplified a bit (no separate
  read/readm; the number of arguments determines whether the user
  wants the result on the console or to a memory address)

- Add tests, both of rtc_{read,write}() and of the shell command,
  fixing a few things I stumbled on.

Rasmus Villemoes (10):
  rtc: add rtc_read helper and ->read method
  rtc: add rtc_write() helper
  rtc: fall back to ->{read,write} if ->{read,write}8 are not provided
  rtc: pcf2127: provide ->read method
  rtc: pcf2127: provide ->write method
  rtc: add rtc command
  rtc: sandbox-rtc: fix set method
  rtc: i2c_rtc_emul: catch any write to the "reset" register
  test: dm: rtc: add test of rtc_read, rtc_write
  test: dm: rtc: add tests of rtc shell command

 arch/sandbox/include/asm/rtc.h |   5 ++
 cmd/Kconfig|   6 ++
 cmd/Makefile   |   1 +
 cmd/rtc.c  | 159 +
 drivers/rtc/i2c_rtc_emul.c |   3 +-
 drivers/rtc/pcf2127.c  |  13 ++-
 drivers/rtc/rtc-uclass.c   |  56 +++-
 drivers/rtc/sandbox_rtc.c  |  65 +-
 include/rtc.h  |  47 ++
 test/dm/rtc.c  | 121 -
 10 files changed, 426 insertions(+), 50 deletions(-)
 create mode 100644 cmd/rtc.c

-- 
2.23.0



[PATCH v2 04/10] rtc: pcf2127: provide ->read method

2020-05-19 Thread Rasmus Villemoes
This simply consists of renaming the existing pcf2127_read_reg()
helper to follow the naming of the other
methods (i.e. pcf2127_rtc_) and changing the type of its
"len" parameter.

Reviewed-by: Simon Glass 
Signed-off-by: Rasmus Villemoes 
---
 drivers/rtc/pcf2127.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index b34ed63bf0..f48cd8cb18 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -22,8 +22,7 @@
 #define PCF2127_REG_MO 0x08
 #define PCF2127_REG_YR 0x09
 
-static int pcf2127_read_reg(struct udevice *dev, uint offset,
-   u8 *buffer, int len)
+static int pcf2127_rtc_read(struct udevice *dev, uint offset, u8 *buffer, uint 
len)
 {
struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
struct i2c_msg msg;
@@ -72,7 +71,7 @@ static int pcf2127_rtc_get(struct udevice *dev, struct 
rtc_time *tm)
int ret = 0;
uchar buf[10] = { PCF2127_REG_CTRL1 };
 
-   ret = pcf2127_read_reg(dev, PCF2127_REG_CTRL1, buf, sizeof(buf));
+   ret = pcf2127_rtc_read(dev, PCF2127_REG_CTRL1, buf, sizeof(buf));
if (ret < 0)
return ret;
 
@@ -109,6 +108,7 @@ static const struct rtc_ops pcf2127_rtc_ops = {
.get = pcf2127_rtc_get,
.set = pcf2127_rtc_set,
.reset = pcf2127_rtc_reset,
+   .read = pcf2127_rtc_read,
 };
 
 static const struct udevice_id pcf2127_rtc_ids[] = {
-- 
2.23.0



Re: [PATCH] doc: rockchip: Update documentation with Rock Pi 4

2020-05-19 Thread Walter Lozano

Hi Tom,

On 19/5/20 18:02, Tom Rini wrote:

On Tue, May 19, 2020 at 05:29:31PM -0300, Walter Lozano wrote:

Hi Jagan

On 19/5/20 15:57, Jagan Teki wrote:

On Wed, May 20, 2020 at 12:15 AM Walter Lozano
 wrote:

Update README.rockchip to reflect the support of Radxa Rock Pi 4

Signed-off-by: Walter Lozano 
---
   doc/README.rockchip | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

We have doc/board/rockchip please update there.

Documentation in doc/board/rockchip already states the support for Radxa
Rock Pi 4. Unfortunately having two different documentation which overlaps
tends to be redundancy prone.


At this point I think that the best approach it to spawn two tasks

1- Update the doc/README.rockchip with any specific information which needs
to be updated

2- Continue to move doc/README.rockchip to doc/board/rockchip as you started
to do


I might find some time to work in task 2, but in the meantime I think this
patch goes in the direction of task 1


Do you agree?

I'd like to see doc/README.rockchip go away in favour of
doc/board/rockchip/ as soon as possible, especially since this is an
area with active development.  I'd rather see an update to
doc/README.rockchip saying that doc/board/rockchip/rockchip.rst has the
list of supported hardware as the step forward here.  Thanks!


OK, it makes sense. I'll prepare such patch and send it.

Regards,

Walter



Re: [PATCH] doc: rockchip: Update documentation with Rock Pi 4

2020-05-19 Thread Tom Rini
On Tue, May 19, 2020 at 05:29:31PM -0300, Walter Lozano wrote:
> Hi Jagan
> 
> On 19/5/20 15:57, Jagan Teki wrote:
> > On Wed, May 20, 2020 at 12:15 AM Walter Lozano
> >  wrote:
> > > Update README.rockchip to reflect the support of Radxa Rock Pi 4
> > > 
> > > Signed-off-by: Walter Lozano 
> > > ---
> > >   doc/README.rockchip | 3 ++-
> > >   1 file changed, 2 insertions(+), 1 deletion(-)
> > We have doc/board/rockchip please update there.
> 
> Documentation in doc/board/rockchip already states the support for Radxa
> Rock Pi 4. Unfortunately having two different documentation which overlaps
> tends to be redundancy prone.
> 
> 
> At this point I think that the best approach it to spawn two tasks
> 
> 1- Update the doc/README.rockchip with any specific information which needs
> to be updated
> 
> 2- Continue to move doc/README.rockchip to doc/board/rockchip as you started
> to do
> 
> 
> I might find some time to work in task 2, but in the meantime I think this
> patch goes in the direction of task 1
> 
> 
> Do you agree?

I'd like to see doc/README.rockchip go away in favour of
doc/board/rockchip/ as soon as possible, especially since this is an
area with active development.  I'd rather see an update to
doc/README.rockchip saying that doc/board/rockchip/rockchip.rst has the
list of supported hardware as the step forward here.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] doc: rockchip: Update documentation with Rock Pi 4

2020-05-19 Thread Walter Lozano

Hi Jagan

On 19/5/20 15:57, Jagan Teki wrote:

On Wed, May 20, 2020 at 12:15 AM Walter Lozano
 wrote:

Update README.rockchip to reflect the support of Radxa Rock Pi 4

Signed-off-by: Walter Lozano 
---
  doc/README.rockchip | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

We have doc/board/rockchip please update there.


Documentation in doc/board/rockchip already states the support for Radxa 
Rock Pi 4. Unfortunately having two different documentation which 
overlaps tends to be redundancy prone.



At this point I think that the best approach it to spawn two tasks

1- Update the doc/README.rockchip with any specific information which 
needs to be updated


2- Continue to move doc/README.rockchip to doc/board/rockchip as you 
started to do



I might find some time to work in task 2, but in the meantime I think 
this patch goes in the direction of task 1



Do you agree?


Regards,


Walter



Re: [PATCH v2 5/5] mtd: spi: Use CONFIG_IS_ENABLED to prevent ifdef

2020-05-19 Thread Jagan Teki
On Thu, May 14, 2020 at 11:41 PM Jagan Teki  wrote:
>
> Use CONFIG_IS_ENABLED to prevent ifdef in sf_probe.c
>
> Cc: Simon Glass 
> Cc: Vignesh R 
> Cc: Daniel Schwierzeck 
> Signed-off-by: Jagan Teki 
> ---

Applied to u-boot-spi/master


Re: [PATCH 4/5] mtd: sf: Drop plat from sf_probe

2020-05-19 Thread Jagan Teki
On Fri, May 15, 2020 at 12:47 PM Pratyush Yadav  wrote:
>
> On 14/05/20 05:41PM, Jagan Teki wrote:
> > dm_spi_slave_platdata used in sf_probe for printing
> > plat->cs value and there is no relevant usage apart
> > from this.
> >
> > We have enouch debug messages available in SPI and SF
>
> s/enouch/enough/

Applied to u-boot-spi/master


Re: [PATCH 2/5] cmd: sf Drop reassignment of new into flash

2020-05-19 Thread Jagan Teki
On Thu, May 14, 2020 at 5:42 PM Jagan Teki  wrote:
>
> The new pointer points to flash found and that would
> assign it to global 'flash' pointer for further flash
> operations and also keep track of old flash pointer.
>
> This would happen if the probe is successful or even
> failed, but current code assigning new into flash before
> and after checking the new.
>
> So, drop the assignment after new checks so flash always
> latest new pointer even if probe failed or succeed.
>
> Cc: Simon Glass 
> Cc: Vignesh R 
> Signed-off-by: Jagan Teki 
> ---

Applied to u-boot-spi/master


[PATCH v2 7/9] sifive: fu540: Mark the default env as SPI flash

2020-05-19 Thread Jagan Teki
Mark the default U-Boot environment as SPI flash since
this is an on board flash device.

Reviewed-by: Bin Meng 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- none

 board/sifive/fu540/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 86193d7668..e1ba629e37 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -27,6 +27,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select SIFIVE_FU540
select SUPPORT_SPL
+   select ENV_IS_IN_SPI_FLASH
select RAM
select SPL_RAM if SPL
imply CMD_DHCP
-- 
2.20.1



[PATCH v2 9/9] sifive: fu540: Enable SF distro bootcmd

2020-05-19 Thread Jagan Teki
Enable SPI flash(SF) distro boot command in Sifive FU540.

This distro boot will read the boot script at specific
location at the flash and start sourcing the same.

Included the SF device at the last of the target devices
list since all the rest of the devices on the list have
more possibility to boot the distribution due to the
size of the SPI flash is concern.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- none

 include/configs/sifive-fu540.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
index 68fda14d76..f21411a701 100644
--- a/include/configs/sifive-fu540.h
+++ b/include/configs/sifive-fu540.h
@@ -43,9 +43,11 @@
 #ifndef CONFIG_SPL_BUILD
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
+   func(SF, sf, 0) \
func(DHCP, dhcp, na)
 
 #include 
+#include 
 
 #define TYPE_GUID_LOADER1  "5B193300-FC78-40CD-8002-E86C45580B47"
 #define TYPE_GUID_LOADER2  "2E54B353-1271-4842-806F-E436D6AF6985"
@@ -70,7 +72,8 @@
"type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \
"type_guid_gpt_system=" TYPE_GUID_SYSTEM "\0" \
"partitions=" PARTS_DEFAULT "\0" \
-   BOOTENV
+   BOOTENV \
+   BOOTENV_SF
 
 #define CONFIG_PREBOOT \
"setenv fdt_addr ${fdtcontroladdr};" \
-- 
2.20.1



[PATCH v4] net: tftp: Add client support for RFC 7440

2020-05-19 Thread Ramon Fried
Add support for RFC 7440: "TFTP Windowsize Option".

This optional feature allows the client and server
to negotiate a window size of consecutive blocks to send as an
alternative for replacing the single-block lockstep schema.

windowsize can be defined statically during compilation by
setting CONFIG_TFTP_WINDOWSIZE, or defined in runtime by
setting an environment variable: "tftpwindowsize"
If not defined, the windowsize is set to 1, meaning that it
behaves as it was never defined.

Choosing the appropriate windowsize depends on the specific
network topology, underlying NIC.
You should test various windowsize scenarios and see which
best work for you.

Setting a windowsize too big can actually decreases performance.

Signed-off-by: Ramon Fried 
Reviewed-by: Marek Vasut 
---
v2:
 * Don't send windowsize option on tftpput, as it's not implemented yet.
 * Don't send NACK for every out of order block that arrives, one nack
   is enough.
v3:
 * Add option CONFIG_TFTP_WINDOWSIZE to kconfig with default 1.
 * Fixed some spelling errors.
 * Took assignment out of a loop.
 * simplified variable increment.
v4:
 * send ack for last packet, so the server can finish
   the tranfer gracefully and not in timeout.

 README  |  5 
 net/Kconfig |  9 ++
 net/tftp.c  | 81 +++--
 3 files changed, 87 insertions(+), 8 deletions(-)

diff --git a/README b/README
index be9e6391d6..686474a2f1 100644
--- a/README
+++ b/README
@@ -3522,6 +3522,11 @@ List of environment variables (most likely not complete):
  downloads succeed with high packet loss rates, or with
  unreliable TFTP servers or client hardware.
 
+  tftpwindowsize   - if this is set, the value is used for TFTP's
+ window size as described by RFC 7440.
+ This means the count of blocks we can receive before
+ sending ack to server.
+
   vlan - When set to a value < 4095 the traffic over
  Ethernet is encapsulated/received over 802.1q
  VLAN tagged frames.
diff --git a/net/Kconfig b/net/Kconfig
index ac6d0cf8a6..7916ae305f 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -49,4 +49,13 @@ config TFTP_BLOCKSIZE
  almost-MTU block sizes.
  You can also activate CONFIG_IP_DEFRAG to set a larger block.
 
+config TFTP_WINDOWSIZE
+   int "TFTP window size"
+   default 1
+   help
+ Default TFTP window size.
+ RFC7440 defines an optional window size of transmits,
+ before an ack response is required.
+ The default TFTP implementation implies a window size of 1.
+
 endif   # if NET
diff --git a/net/tftp.c b/net/tftp.c
index be24e63075..72d23e1574 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -5,7 +5,6 @@
  * Copyright 2011 Comelit Group SpA,
  *Luca Ceresoli 
  */
-
 #include 
 #include 
 #include 
@@ -95,6 +94,12 @@ static int   tftp_tsize;
 /* The number of hashes we printed */
 static short   tftp_tsize_num_hash;
 #endif
+/* The window size negotiated */
+static ushort  tftp_windowsize;
+/* Next block to send ack to */
+static ushort  tftp_next_ack;
+/* Last nack block we send */
+static ushort  tftp_last_nack;
 #ifdef CONFIG_CMD_TFTPPUT
 /* 1 if writing, else 0 */
 static int tftp_put_active;
@@ -134,8 +139,19 @@ static char tftp_filename[MAX_LEN];
  * (but those using CONFIG_IP_DEFRAG may want to set a larger block in cfg 
file)
  */
 
+/* When windowsize is defined to 1,
+ * tftp behaves the same way as it was
+ * never declared
+ */
+#ifdef CONFIG_TFTP_WINDOWSIZE
+#define TFTP_WINDOWSIZE CONFIG_TFTP_WINDOWSIZE
+#else
+#define TFTP_WINDOWSIZE 1
+#endif
+
 static unsigned short tftp_block_size = TFTP_BLOCK_SIZE;
 static unsigned short tftp_block_size_option = CONFIG_TFTP_BLOCKSIZE;
+static unsigned short tftp_window_size_option = TFTP_WINDOWSIZE;
 
 static inline int store_block(int block, uchar *src, unsigned int len)
 {
@@ -348,6 +364,14 @@ static void tftp_send(void)
/* try for more effic. blk size */
pkt += sprintf((char *)pkt, "blksize%c%d%c",
0, tftp_block_size_option, 0);
+
+   /* try for more effic. window size.
+* Implemented only for tftp get.
+* Don't bother sending if it's 1
+*/
+   if (tftp_state == STATE_SEND_RRQ && tftp_window_size_option > 1)
+   pkt += sprintf((char *)pkt, "windowsize%c%d%c",
+   0, tftp_window_size_option, 0);
len = pkt - xp;
break;
 
@@ -500,7 +524,18 @@ static void tftp_handler(uchar *pkt, unsigned dest, struct 
in_addr sip,
  (char *)pkt + i + 6, tftp_tsize);
}
 #endif
+   if (strcmp((char *)pkt + i,  "windowsize") == 0) {
+   tftp_windowsize =
+  

[PATCH v2 8/9] sifive: fu540: Add boot flash script offset, size

2020-05-19 Thread Jagan Teki
HiFive-Unleashed-A00 has SPI flash with 32MiB size.
So, let's use the script offset at the end of 4K.
This way it cannot overlap any offsets being used
by software components in flash layout.

So, SF distrocmd will pick the script at desired
script address and run.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- none

 include/configs/sifive-fu540.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
index 72c841eb9b..68fda14d76 100644
--- a/include/configs/sifive-fu540.h
+++ b/include/configs/sifive-fu540.h
@@ -62,6 +62,8 @@
"kernel_addr_r=0x8400\0" \
"fdt_addr_r=0x8800\0" \
"scriptaddr=0x8810\0" \
+   "script_offset_f=0x1fff000\0" \
+   "script_size_f=0x1000\0" \
"pxefile_addr_r=0x8820\0" \
"ramdisk_addr_r=0x8830\0" \
"type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \
-- 
2.20.1



[PATCH v2 6/9] env: Enable SPI flash env for SiFive FU540

2020-05-19 Thread Jagan Teki
SPI flash device on HiFive Unleashed has 32MiB Size.

This patch add SPI flash environment after U-Boot proper
partition with a size of 128KiB.

SPI flash partition layout(32MiB):
0 - 34  : reserved for GPT header
   35 - 39  : unused
   40 - 2087: loader1 (SPL, FSBL)
 2088 - 10279   : loader2 (U-Boot proper, U-Boot)
10280 - 10535   : environment
10536 - 65494   : rootfs
65528 - 65536   : distro script

Note: the loader1 must start from 40th sector even though
there are 6 free sectors prior since 40th sector is nearest
flash sector boundary. 

Signed-off-by: Jagan Teki 
---
Changes for v2:
- move env offsets from generic to cpu Kconfig

 arch/riscv/cpu/fu540/Kconfig | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
index 7a813a9ac8..417926d2cf 100644
--- a/arch/riscv/cpu/fu540/Kconfig
+++ b/arch/riscv/cpu/fu540/Kconfig
@@ -15,3 +15,16 @@ config SIFIVE_FU540
imply SPL_CPU_SUPPORT
imply SPL_OPENSBI
imply SPL_LOAD_FIT
+
+if CONFIG_ENV_IS_IN_SPI_FLASH
+
+config ENV_OFFSET
+   default 0x505000
+
+config ENV_SIZE
+   default 0x2
+
+config ENV_SECT_SIZE
+   default 0x1
+
+endif # CONFIG_ENV_IS_IN_SPI_FLASH
-- 
2.20.1



[PATCH v2 5/9] sifive: fu540: Add Booting from SPI

2020-05-19 Thread Jagan Teki
U-Boot SPL 2020.07-rc2-00156-gb9abb0716a-dirty (May 19 2020 - 21:56:17 +0530)
Trying to boot from SPI

U-Boot 2020.07-rc2-00156-gb9abb0716a-dirty (May 19 2020 - 21:56:17 +0530)

CPU:   rv64imafdc
Model: SiFive HiFive Unleashed A00
DRAM:  8 GiB
No reserved memory region found in source FDT
MMC:   spi@1005:mmc@0: 0
In:serial@1001
Out:   serial@1001
Err:   serial@1001
Net:   eth0: ethernet@1009
Hit any key to stop autoboot:  0

Signed-off-by: Jagan Teki 
---
Changes for v2:
- enable board driver
- comment spl-payloade-offset
- reference for SPI partition

 arch/riscv/cpu/fu540/Kconfig  |  2 +
 .../dts/hifive-unleashed-a00-u-boot.dtsi  | 12 ++
 board/sifive/fu540/fu540.c| 12 --
 configs/sifive_fu540_defconfig|  4 ++
 doc/board/sifive/fu540.rst| 41 +++
 5 files changed, 59 insertions(+), 12 deletions(-)

diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
index e9302e87c0..7a813a9ac8 100644
--- a/arch/riscv/cpu/fu540/Kconfig
+++ b/arch/riscv/cpu/fu540/Kconfig
@@ -5,6 +5,8 @@
 config SIFIVE_FU540
bool
select ARCH_EARLY_INIT_R
+   imply BOARD
+   imply BOARD_FU540
imply CPU
imply CPU_RISCV
imply RISCV_TIMER
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
index 303806454b..4b2b242deb 100644
--- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -12,6 +12,10 @@
spi2 = 
};
 
+   config {
+   u-boot,spl-payload-offset = <0x105000>; /* loader2 @1044KB */
+   };
+
hfclk {
u-boot,dm-spl;
};
@@ -22,6 +26,14 @@
 
 };
 
+ {
+   u-boot,dm-spl;
+
+   flash@0 {
+   u-boot,dm-spl;
+   };
+};
+
  {
mmc@0 {
u-boot,dm-spl;
diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
index 535ab60aed..a7b530b281 100644
--- a/board/sifive/fu540/fu540.c
+++ b/board/sifive/fu540/fu540.c
@@ -116,18 +116,6 @@ int board_init(void)
return 0;
 }
 
-#ifdef CONFIG_SPL
-u32 spl_boot_device(void)
-{
-#ifdef CONFIG_SPL_MMC_SUPPORT
-   return BOOT_DEVICE_MMC1;
-#else
-   puts("Unknown boot device\n");
-   hang();
-#endif
-}
-#endif
-
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 8d412f8d6a..551d4b04a5 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -2,9 +2,11 @@ CONFIG_RISCV=y
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x3000
 CONFIG_ENV_SIZE=0x2
+CONFIG_SPL_DM_SPI=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_TARGET_SIFIVE_FU540=y
 CONFIG_ARCH_RV64I=y
@@ -15,9 +17,11 @@ CONFIG_MISC_INIT_R=y
 CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_OF_BOARD_FIXUP=y
 CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_CLK=y
 CONFIG_DM_MTD=y
diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
index 9e9ae98b64..d3d38eb966 100644
--- a/doc/board/sifive/fu540.rst
+++ b/doc/board/sifive/fu540.rst
@@ -541,3 +541,44 @@ Sample boot log from HiFive Unleashed board
type:   0fc63daf-8483-4772-8e79-3d69d8477de4
type:   linux
guid:   9faa81b6-39b1-4418-af5e-89c48f29c20d
+
+Booting from SPI
+
+
+Use Building steps from "Booting from MMC using U-Boot SPL" section.
+
+Partition the SPI in Linux via mtdblock. (Require to boot the board in
+SD boot mode by enabling MTD block in Linux)
+
+Use prebuilt image from here [1], which support to partition the SPI flash.
+
+.. code-block:: none
+
+  # sgdisk --clear \
+  > --set-alignment=2 \
+  > --new=1:40:2087 --change-name=1:loader1 
--typecode=1:5B193300-FC78-40CD-8002-E86C45580B47 \
+  > --new=2:2088:10279 --change-name=2:loader2 
--typecode=2:2E54B353-1271-4842-806F-E436D6AF6985 \
+  > --new=3:10536:65494 --change-name=3:rootfs 
--typecode=3:0FC63DAF-8483-4772-8E79-3D69D8477DE4 \
+  > /dev/mtdblock0
+
+Program the SPI (Require to boot the board in SD boot mode)
+
+Execute below steps on U-Boot proper,
+
+.. code-block:: none
+
+  sf erase 0x5000 0x10
+  tftpboot $kernel_addr_r u-boot-spl.bin
+  sf write $kernel_addr_r 0x5000 $filesize
+
+  sf erase 0x105000 0x10
+  tftpboot $kernel_addr_r u-boot.itb
+  sf write $kernel_addr_r 0x105000 $filesize
+
+Power off the board
+
+Change DIP switches MSEL[3:0] are set to 0110
+
+Power up the board.
+
+[1] https://github.com/amarula/bsp-sifive
-- 
2.20.1



[PATCH v2 3/9] riscv: dts: fu540-c000-u-boot: Add sifive, fu540-modeselect

2020-05-19 Thread Jagan Teki
Add sifive,fu540-modeselect node, which usually get runtime
boot mode of fu540 boards.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- new patch

 arch/riscv/dts/fu540-c000-u-boot.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi 
b/arch/riscv/dts/fu540-c000-u-boot.dtsi
index fc91a7c987..0ccda0e59b 100644
--- a/arch/riscv/dts/fu540-c000-u-boot.dtsi
+++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
@@ -48,6 +48,13 @@
 
soc {
u-boot,dm-spl;
+
+   board: mode@1000 {
+   compatible = "sifive,fu540-modeselect";
+   reg = <0x0 0x1000 0x0 0x1FFF>;
+   u-boot,dm-spl;
+   };
+
otp: otp@1007 {
compatible = "sifive,fu540-c000-otp";
reg = <0x0 0x1007 0x0 0x0FFF>;
-- 
2.20.1



[PATCH v2 4/9] drivers: Add fu540 board driver

2020-05-19 Thread Jagan Teki
Add fu540 board driver, which is used to get runtime
boot mode of fu540 boards.

Cc: Mario Six 
Cc: Tom Rini 
Cc: Simon Glass 
Cc: Jean-Jacques Hiblot 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- new patch

 drivers/board/Kconfig  |  8 
 drivers/board/Makefile |  1 +
 drivers/board/fu540.c  | 86 ++
 3 files changed, 95 insertions(+)
 create mode 100644 drivers/board/fu540.c

diff --git a/drivers/board/Kconfig b/drivers/board/Kconfig
index 254f657049..306ee76bbd 100644
--- a/drivers/board/Kconfig
+++ b/drivers/board/Kconfig
@@ -12,6 +12,14 @@ config SPL_BOARD
depends on SPL_DM
bool "Enable board driver support in SPL"
 
+config BOARD_FU540
+   bool "Enable board driver for the FU540 boards"
+   depends on RISCV
+   select SPL_BOARD
+   help
+ Support querying board information for the fu540 boards, like
+ get soc mode select, get SPL boot device and etc.
+
 config BOARD_GAZERBEAM
bool "Enable board driver for the Gazerbeam board"
help
diff --git a/drivers/board/Makefile b/drivers/board/Makefile
index cc16361755..e924472779 100644
--- a/drivers/board/Makefile
+++ b/drivers/board/Makefile
@@ -3,5 +3,6 @@
 # (C) Copyright 2017
 # Mario Six,  Guntermann & Drunck GmbH, mario@gdsys.cc
 obj-y += board-uclass.o
+obj-$(CONFIG_BOARD_FU540) += fu540.o
 obj-$(CONFIG_BOARD_GAZERBEAM) += gazerbeam.o
 obj-$(CONFIG_BOARD_SANDBOX) += sandbox.o
diff --git a/drivers/board/fu540.c b/drivers/board/fu540.c
new file mode 100644
index 00..68d356df6b
--- /dev/null
+++ b/drivers/board/fu540.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Amarula Solutions(India)
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MODE_SELECT_QSPI   0x6
+#define MODE_SELECT_SD 0xb
+#define MODE_SELECT_MASK   GENMASK(3, 0)
+
+struct fu540_board {
+   void __iomem *regs;
+};
+
+static int fu540_get_boot_device(struct udevice *dev)
+{
+   struct fu540_board *priv = dev_get_priv(dev);
+   u8 boot_device = BOOT_DEVICE_MMC1;
+   u32 reg;
+
+   reg = readl(priv->regs);
+   switch (reg & MODE_SELECT_MASK) {
+   case MODE_SELECT_QSPI:
+   boot_device = BOOT_DEVICE_SPI;
+   break;
+   case MODE_SELECT_SD:
+   boot_device = BOOT_DEVICE_MMC1;
+   break;
+   default:
+   dev_err(dev,
+   "Unsupported boot device 0x%x but trying MMC1\n",
+   boot_device);
+   break;
+   }
+
+   return boot_device;
+}
+
+static int fu540_board_get_int(struct udevice *dev, int id, int *val)
+{
+   switch (id) {
+   case BOARD_SPL_BOOT_DEVICE:
+   *val = fu540_get_boot_device(dev);
+   break;
+   default:
+   dev_err(dev, "%s: Integer value %d unknown\n", dev->name, id);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static const struct board_ops fu540_board_ops = {
+   .get_int = fu540_board_get_int,
+};
+
+static int fu540_board_probe(struct udevice *dev)
+{
+   struct fu540_board *priv = dev_get_priv(dev);
+
+   priv->regs = (void __iomem *)dev_read_addr(dev);
+   if (IS_ERR(priv->regs))
+   return PTR_ERR(priv->regs);
+
+   return 0;
+}
+
+static const struct udevice_id fu540_board_ids[] = {
+   { .compatible = "sifive,fu540-modeselect", },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(fu540_board) = {
+   .id = UCLASS_BOARD,
+   .name   = "fu540_board",
+   .of_match   = fu540_board_ids,
+   .ops= _board_ops,
+   .priv_auto_alloc_size = sizeof(struct fu540_board),
+   .probe  = fu540_board_probe,
+};
-- 
2.20.1



[PATCH v2 0/9] riscv: sifive/fu540: Booting from SPI

2020-05-19 Thread Jagan Teki
This series support Boot from SPI on SiFive FU540 HiFive Unleashed 
board, with improved version of detecting bootmode at runtime.

Previous version changes are at [1].

Changes for v2:
- fu540 board driver
- runtime bootmode detection
- rebase on Pragnesh v11 series

[1] 
https://patchwork.ozlabs.org/project/uboot/cover/20200420140514.25847-1-ja...@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (9):
  spl: Try to get SPL boot device via board_get_int
  dt-bindings: board: Document sifive,fu540-modeselect
  riscv: dts: fu540-c000-u-boot: Add sifive,fu540-modeselect
  drivers: Add fu540 board driver
  sifive: fu540: Add Booting from SPI
  env: Enable SPI flash env for SiFive FU540
  sifive: fu540: Mark the default env as SPI flash
  sifive: fu540: Add boot flash script offset, size
  sifive: fu540: Enable SF distro bootcmd

 arch/riscv/cpu/fu540/Kconfig  | 15 
 arch/riscv/dts/fu540-c000-u-boot.dtsi |  7 ++
 .../dts/hifive-unleashed-a00-u-boot.dtsi  | 12 +++
 board/sifive/fu540/Kconfig|  1 +
 board/sifive/fu540/fu540.c| 12 ---
 common/spl/spl.c  | 14 ++-
 configs/sifive_fu540_defconfig|  4 +
 doc/board/sifive/fu540.rst| 41 +
 .../board/sifive,fu540-modeselect.txt | 15 
 drivers/board/Kconfig |  8 ++
 drivers/board/Makefile|  1 +
 drivers/board/fu540.c | 86 +++
 include/board.h   |  9 ++
 include/configs/sifive-fu540.h|  7 +-
 14 files changed, 218 insertions(+), 14 deletions(-)
 create mode 100644 doc/device-tree-bindings/board/sifive,fu540-modeselect.txt
 create mode 100644 drivers/board/fu540.c

-- 
2.20.1



[PATCH v2 2/9] dt-bindings: board: Document sifive,fu540-modeselect

2020-05-19 Thread Jagan Teki
Add dt-bindings documentation for sifive,fu540-modeselect board
driver, which usually get runtime boot mode of fu540 boards.

Cc: Simon Glass 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- new patch

 .../board/sifive,fu540-modeselect.txt | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 doc/device-tree-bindings/board/sifive,fu540-modeselect.txt

diff --git a/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt 
b/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt
new file mode 100644
index 00..801c068390
--- /dev/null
+++ b/doc/device-tree-bindings/board/sifive,fu540-modeselect.txt
@@ -0,0 +1,15 @@
+fu540 board driver
+
+This driver provides capabilities to get the current boot device for
+fu540 associated board.
+
+Required properties:
+- compatible:  should be "sifive,fu540-modeselect"
+- reg: physical base address and size of fu540 modeselct
+
+Example:
+
+board: mode@1000 {
+   compatible = "sifive,fu540-modeselect";
+   reg = <0x0 0x1000 0x0 0x1FFF>;
+};
-- 
2.20.1



[PATCH v2 1/9] spl: Try to get SPL boot device via board_get_int

2020-05-19 Thread Jagan Teki
Usually, the associated board would supply spl boot device
using spl_boot_device() but some boards have board driver
that are possible to supply boot device via board_get_int
with BOARD_SPL_BOOT_DEVICE id.

This patch add support for those.

Cc: Mario Six 
Cc: Tom Rini 
Cc: Simon Glass 
Cc: Jean-Jacques Hiblot 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- new patch

 common/spl/spl.c | 14 +-
 include/board.h  |  9 +
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index fc5cbbbeba..a07b71b3c1 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -483,9 +484,20 @@ int spl_init(void)
 #define BOOT_DEVICE_NONE 0xdeadbeef
 #endif
 
+__weak u32 spl_boot_device(void)
+{
+   return 0;
+}
+
 __weak void board_boot_order(u32 *spl_boot_list)
 {
-   spl_boot_list[0] = spl_boot_device();
+   struct udevice *board;
+
+   if (!board_get())
+   board_get_int(board, BOARD_SPL_BOOT_DEVICE,
+ (int *)_boot_list[0]);
+   else
+   spl_boot_list[0] = spl_boot_device();
 }
 
 static struct spl_image_loader *spl_ll_find_loader(uint boot_device)
diff --git a/include/board.h b/include/board.h
index 678b652b0a..ce4eaba38d 100644
--- a/include/board.h
+++ b/include/board.h
@@ -211,3 +211,12 @@ static inline int board_get_fit_loadable(struct udevice 
*dev, int index,
 }
 
 #endif
+
+/**
+ * Common board unique identifier
+ *
+ * @BOARD_SPL_BOOT_DEVICE: id to get SPL boot device.
+ */
+enum common_ids {
+   BOARD_SPL_BOOT_DEVICE,
+};
-- 
2.20.1



Re: [PATCH 1/5] mtd: spi: Call sst_write in _write ops

2020-05-19 Thread Jagan Teki
On Thu, May 14, 2020 at 5:41 PM Jagan Teki  wrote:
>
> Currently spi-nor code is assigning _write ops for SST
> and other flashes separately.
>
> Just call the sst_write from generic write ops and return
> if SST flash found, this way it avoids the confusion of
> multiple write ops assignment during the scan and makes
> it more feasible for code readability.
>
> No functionality changes.
>
> Cc: Simon Glass 
> Cc: Vignesh R 
> Signed-off-by: Jagan Teki 
> ---

Applied to u-boot-spi/master


Re: [PATCH] doc: rockchip: Update documentation with Rock Pi 4

2020-05-19 Thread Jagan Teki
On Wed, May 20, 2020 at 12:15 AM Walter Lozano
 wrote:
>
> Update README.rockchip to reflect the support of Radxa Rock Pi 4
>
> Signed-off-by: Walter Lozano 
> ---
>  doc/README.rockchip | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

We have doc/board/rockchip please update there.

Jagan.


Re: [PATCH v11 18/18] doc: sifive: fu540: Add description for OpenSBI generic platform

2020-05-19 Thread Jagan Teki
On Tue, May 19, 2020 at 12:35 PM Pragnesh Patel
 wrote:
>
> OpenSBI generic platform support provides platform specific
> functionality based on the FDT passed by previous booting stage.
>
> Depends on OpenSBI commit:
> platform: Add generic FDT based platform support
> (sha1: f1aa9e54e6ae70aeac638d5b75093520f65d)
>
> Signed-off-by: Pragnesh Patel 
> Reviewed-by: Bin Meng 
> ---

Reviewed-by: Jagan Teki 


  1   2   3   >