Re: [PATCH v2] tools: Add script to update git subtree projects

2024-07-24 Thread Sumit Garg
Hi Raymond,

Thanks for doing this.

On Tue, 23 Jul 2024 at 01:01, Raymond Mao  wrote:
>
> Recently we are introducing multiple git subtree projects and
> it is the right time to have a universal script to update
> various subtrees and replace the dts/update-dts-subtree.sh.
>
> update-subtree.sh is a wrapper of git subtree commands.
>
> Usage: From U-Boot top directory,
> run
> $ ./tools/update-subtree.sh pull  
> for pulling a tag from the upstream.
> Or run
> $ ./tools/update-subtree.sh pick  
> for cherry-pick a commit from the upstream.
>
> Currently  supports dts, mbedtls and lwip.
>
> Signed-off-by: Raymond Mao 
> ---
> Changes in v2
> - Refactored the script.
> - Update the control doc.
>
>  doc/develop/devicetree/control.rst |  8 +--
>  dts/update-dts-subtree.sh  | 48 -
>  tools/update-subtree.sh| 86 ++
>  3 files changed, 90 insertions(+), 52 deletions(-)
>  delete mode 100755 dts/update-dts-subtree.sh
>  create mode 100755 tools/update-subtree.sh
>
> diff --git a/doc/develop/devicetree/control.rst 
> b/doc/develop/devicetree/control.rst
> index ca4fb0b5b10..211f7e4909c 100644
> --- a/doc/develop/devicetree/control.rst
> +++ b/doc/develop/devicetree/control.rst
> @@ -96,12 +96,12 @@ sync the `dts/upstream/` subtree from the 
> devicetree-rebasing repo whenever
>  the next branch opens (refer: :doc:`../release_cycle`) with the latest 
> mainline
>  Linux kernel release. To sync the `dts/upstream/` subtree, run::
>
> -./dts/update-dts-subtree.sh pull 
> +./tools/update-subtree.sh pull dts 
>
>  If required it is also possible to cherry-pick fixes from the
>  devicetree-rebasing repository prior to next sync, usage::
>
> -./dts/update-dts-subtree.sh pick 
> +./tools/update-subtree.sh pick dts 
>
>
>  Configuration
> @@ -116,8 +116,8 @@ However, if `dts/upstream/` hasn't yet received 
> devicetree source file for your
>  newly added board support then one option is that you can add the 
> corresponding
>  devicetree source file as `arch//dts/.dts`. To select that add `#
>  CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=` when
> -prompted by Kconfig. Another option is that you can use use the "pick" 
> option of
> -`dts/update-dts-subtree.sh` mentioned above to bring in the commits that you
> +prompted by Kconfig. Another option is that you can use the "pick" option of
> +`tools/update-subtree.sh` mentioned above to bring in the commits that you
>  need.
>
>  This should include your CPU or SoC's devicetree file. On top of that any 
> U-Boot
> diff --git a/dts/update-dts-subtree.sh b/dts/update-dts-subtree.sh
> deleted file mode 100755
> index a57b78a41d3..000
> --- a/dts/update-dts-subtree.sh
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -#!/bin/sh
> -# SPDX-License-Identifier: GPL-2.0+
> -#
> -# Copyright 2024 Linaro Ltd.
> -#
> -# Usage: from the top level U-Boot source tree, run:
> -# $ ./dts/update-dts-subtree.sh pull 
> -# $ ./dts/update-dts-subtree.sh pick 
> -#
> -# The script will pull changes from devicetree-rebasing repo into U-Boot
> -# as a subtree located as /dts/upstream sub-directory. It will
> -# automatically create a squash/merge commit listing the commits imported.
> -
> -set -e
> -
> -merge_commit_msg=$(cat << EOF
> -Subtree merge tag '$2' of devicetree-rebasing repo [1] into dts/upstream
> -
> -[1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> -EOF
> -)
> -
> -remote_add_and_fetch() {
> -if ! git remote get-url devicetree-rebasing 2>/dev/null
> -then
> -echo "Warning: Script automatically adds new git remote via:"
> -echo "git remote add devicetree-rebasing \\"
> -echo "
> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git;
> -git remote add devicetree-rebasing \
> -
> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> -fi
> -git fetch devicetree-rebasing master
> -}
> -
> -if [ "$1" = "pull" ]
> -then
> -remote_add_and_fetch
> -git subtree pull --prefix dts/upstream devicetree-rebasing \
> -"$2" --squash -m "${merge_commit_msg}"
> -elif [ "$1" = "pick" ]
> -then
> -remote_add_and_fetch
> -git cherry-pick -x --strategy=subtree -Xsubtree=dts/upstream/ "$2"
> -else
> -echo "usage: $0  "
> -echo "   pull or pick"
> -echo "  release tag [pull] or commit id [pick]"
> -fi
> diff --git a/tools/update-subtree.sh b/tools/update-subtree.sh
> new file mode 100755
> index 000..5946aa1a9e2
> --- /dev/null
> +++ b/tools/update-subtree.sh
> @@ -0,0 +1,86 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2024 Linaro Limited
> +# Author: Raymond Mao 
> +#
> +# Usage: from the top level U-Boot source tree, run:
> +# $ ./tools/update-subtree.sh pull  
> +# Or:
> +# $ ./tools/update-subtree.sh pick  
> +#
> +# The script will pull changes from subtree 

Re: [PATCH v4 00/21] qcom: rpmh core and regulator support

2024-07-10 Thread Sumit Garg
Hi Caleb,

On Tue, 9 Jul 2024 at 15:04, Caleb Connolly  wrote:
>
> This series introduces support for the RPMh (Resource Power Manager
> (hardened)) co-processor and associated regulator driver found on most
> modern Qualcomm platforms (since ~2017).
>
> Even though most regulators are controlled via SPMI, the specific
> regions on the PMICs for controlling the regulators are restricted and
> can't be accessed by the Applications Processor (AP/HLOS). Instead,
> these resources are proxied via the RPMh where they can be voted on by
> multiple subsystems (Linux, the modem, and the other DSPs). This is done
> for security (to protect clocks, power domains, and regulators that are
> specifically relevant for the trustzone) as well as to simplify the
> management of shared peripherals and to allow for handover of
> peripherals like the USB controller.
>
> For U-Boot, our main concern is the regulators. Since all regulators on
> the system are controlled via the RPMh, it is necessary to support it to
> enable USB VBUS on some platforms, and may be needed for other
> peripherals in the future.
>
> Communicating with the RPMh additional requires accessing the cmd-db
> shared memory region, this contains key/value maps to determine the
> address of specific resources on the RPMh.
>
> Introduce support for the cmd-db, the RPMh framework, and some of the
> regulators that are necessary to enable USB VBUS on the RB5 development
> board.
>
> These drivers are taken from Linux, then modified and simplified for
> U-Boot. The original Linux drivers contain heavy optimisations related
> to multithreading and asynchronous probing, as well as support for idle
> and suspend states which we don't need to deal with here. This unused
> code is removed before finally adjusting the drivers to properly build
> for U-Boot and use its device model.
>
> The U-Boot version of the driver supports a single ACTIVE_ONLY TCS and
> waits for it to be cleared after use. We don't support programming
> low power states.
>
> ---
> Changes in v4:
> - Denote original Linux version in bitmap.h patch
> - Rebased on Linux 6.10-rc6 and re-apply U-Boot changes preserving git
>   history. Allowing for future changes to the Linux drivers to be ported
>   over more easily.
> - Add missing check to wait for the TCS to be cleared after use (seems
>   we were just racing the RPMh before, oops!).
> - Fix missing n_modes in pmic5_pldo regulator.
> - Link to v3: 
> https://lore.kernel.org/r/20240708-b4-qcom-rpmh-v3-0-846cc6c5b...@linaro.org

Thanks for doing this, this looks much better from a maintainability
perspective. Although I am seeing a lot of patches saying adjustments
and build fixes, I think you should have taken care of commits
bisect-ability such that individual commits don't cause any build
errors.

FWIW, for the series:

Acked-by: Sumit Garg 

-Sumit

>
> Changes in v3:
> - Don't call dm_scan_fdt_dev(), since DM core will scan.
> - Link to v2: 
> https://lore.kernel.org/r/20240708-b4-qcom-rpmh-v2-0-8bc765606...@linaro.org
>
> Changes in v2:
> - Implement Neil's suggestions and fixes for SM8[56]50
> - Slightly refactor cmd_db_init() for better abstraction.
> - Improve logging (printf -> log_err/dev_err)
> - Add missing error check in rpmh_regulators_bind()
> - Link to v1: 
> https://lore.kernel.org/r/20240617-b4-qcom-rpmh-v1-0-bd2336923...@linaro.org
>
> ---
> Caleb Connolly (21):
>   linux/bitmap.h: add bitmap_empty helper
>   soc: qcom: import rpmh and cmd-db drivers from Linux
>   soc: qcom: cmd-db: adjust headers for U-Boot
>   soc: qcom: cmd-db: drop unused functions
>   soc: qcom: cmd-db: replace cmd_db_ready() with cmd_db_init()
>   soc: qcom: cmd-db: adjust for U-Boot API
>   soc: qcom: rpmh-rsc: drop unused multi-threading and non-active TCS 
> support
>   soc: qcom: rpmh-rsc: adjust headers for U-Boot
>   soc: qcom: rpmh-rsc: adjust probe for U-Boot
>   soc: qcom: rpmh-rsc: remaining U-Boot API changes
>   soc: qcom: rpmh: adjust headers for U-Boot
>   soc: qcom: rpmh: drop unused functions
>   soc: qcom: rpmh: U-Boot API changes
>   power: regulator: import qcom-rpmh-regulator from Linux
>   power: regulator: adjust headers for U-Boot
>   power: regulator: qcom-rpmh-regulator: port over lineage_range helpers
>   power: regulator: adjust structs for U-Boot
>   power: regulator: qcom-rpmh-regulator: remove unused regulators
>   power: regulator: qcom-rpmh-regulator: port ops to U-Boot
>   power: regulator: qcom-rpmh-regulator: adjust probe for U-Boot
>   qcom_defconfig: enable rpmh regulators
>
>  configs/qcom_defconfig|   5 +
>  drivers/power/regulator/Kconfig

Re: [PATCH 2/3] soc: qcom: rpmh and cmd-db drivers

2024-07-08 Thread Sumit Garg
Hi Caleb,

On Mon, 8 Jul 2024 at 16:13, Caleb Connolly  wrote:
>
> Hi Sumit,
>
> Sorry for the late response.
>
> In general, I'd rather keep this port closer to the Linux original, so
> that future cherry-picking of new features and fixes is easier. This is
> quite standard practice in U-Boot (and why the compatibility macro's are
> included in the first place).
>
> Otherwise, we end up with our own quite different implementation, with
> the higher maintenance burden that comes with it.
>
> This port doesn't do a perfect job at keeping close to upstream, but
> still I don't think we should stray further without a good justification.
>

As per your cover letter:

Quote:
   "These drivers were originally taken from Linux, however they have been
heavily modified and simplified for U-Boot. Since the original Linux
drivers contained heavy optimisations related to multithreading and
asynchronous probing, as well as support for idle and suspend states
which we don't need to deal with here."

This made me think the driver is nowhere close to Linux driver
functionality wise. Also, the commit message doesn't say which Linux
commit this driver is influenced from. I am not really sure if
cherry-picking will be straight forward. IMHO, if we are heavily
modifying a driver port for U-Boot then it should be done properly as
per U-Boot needs. A middle ground approach which you have taken is
only going to lead to confusion and rather negatively impact
maintenance.

-Sumit

> Kind regards,
>
> >> +EXPORT_SYMBOL(cmd_db_read_addr);
> >
> > Export symbols aren't required in U-Boot here and other instances in this 
> > patch.
>
> ...
>
> >> +   /*
> >> +* Wait until we read back the same value.  Use a counter rather 
> >> than
> >> +* ktime for timeout since this may be called after timekeeping 
> >> stops.
> >> +*/
> >> +   for (i = 0; i < USEC_PER_SEC; i++) {
> >> +   if (readl(addr) == data)
> >> +   return;
> >> +   udelay(1);
> >> +   }
> >
> > Can we rather use readx_poll_sleep_timeout() here instead?
>
> ...
> >> +   for (i = 0; i < 5 * USEC_PER_SEC; i++) {
> >> +   if (readl(tcs_reg_addr(drv, reg, tcs_id)) & BIT(tcs_id))
> >> +   break;
> >> +   udelay(1);
> >> +   }
> >
> > Can we rather use readx_poll_sleep_timeout() here instead?
>
> ...
>
> >> +
> >> +   spin_lock_irqsave(>lock, flags);
> >
> > Locks aren't needed in U-Boot, can be dropped here and other places.
> >
>
> ...
>
> >> +
> >> +   spin_lock_init(>lock);
> >> +   init_waitqueue_head(>tcs_wait);
> >
> > Similarly waitqueue should be dropped too.
> >
> > -Sumit
>
> --
> // Caleb (they/them)


Re: [PATCH 0/3] rockchip: enable PCIe/NVMe support for Theobroma RK3588 devices

2024-07-04 Thread Sumit Garg
Hi Quentin,

On Thu, 4 Jul 2024 at 18:23, Quentin Schulz  wrote:
>
> Jaguar has an M.2 M-KEY slot for NVMes and Tiger exposes the signals to
> the Q7 connector which is then routed on the Haikou devkit's `PCI
> Express` connector. With the help of a PCIe to NVMe adapter, NVMes can
> be used on Tiger Haikou as well.
>
> Signed-off-by: Quentin Schulz 
> ---
> Heiko Stuebner (1):
>   arm64: dts: rockchip: add PCIe3 support on rk3588-jaguar
>

Feels really nice to see subtree cherry picking in action here.

> Quentin Schulz (2):
>   rockchip: jaguar-rk3588: add PCIe M.2 M-KEY NVMe support
>   rockchip: tiger-rk3588: add PCIe support
>
>  configs/jaguar-rk3588_defconfig   |  5 ++
>  configs/tiger-rk3588_defconfig|  4 ++
>  dts/upstream/src/arm64/rockchip/rk3588-jaguar.dts | 59 
> +++
>  3 files changed, 68 insertions(+)

FWIW, for the series:

Acked-by: Sumit Garg 

-Sumit

> ---
> base-commit: 0f073e022ddc5070e5df1d053e4bdc1874fbcc0f
> change-id: 20240704-tsd-rk3588-nvme-aa133c24cb9e
>
> Best regards,
> --
> Quentin Schulz 
>


Re: [PATCH] mach-snapdragon: move default environment to a file

2024-06-21 Thread Sumit Garg
On Fri, 21 Jun 2024 at 15:14, Caleb Connolly  wrote:
>
>
>
> On 21/06/2024 10:07, Sumit Garg wrote:
> > On Fri, 21 Jun 2024 at 13:19, Caleb Connolly  
> > wrote:
> >>
> >>
> >>
> >> On 21/06/2024 09:35, Sumit Garg wrote:
> >>> Hi Caleb,
> >>>
> >>> On Mon, 17 Jun 2024 at 14:26, Caleb Connolly  
> >>> wrote:
> >>>>
> >>>> Make use of CONFIG_DEFAULT_ENV_FILE and move the default qcom
> >>>> environment to a file under board/qualcomm.
> >>>>
> >>>> This is much cleaner and means we don't need to recompile on changing
> >>>> the environment.
> >>>>
> >>>> Additionally, extend the environment to include a boot menu and
> >>>> auto-boot using EFI instead of bootm. Since we now support MMC and USB
> >>>> on most platforms, these are much more useful defaults.
> >>>>
> >>>> Signed-off-by: Caleb Connolly 
> >>>> ---
> >>>>board/qualcomm/default.env | 12 
> >>>>configs/qcom_defconfig |  2 ++
> >>>>include/configs/qcom.h |  7 ---
> >>>>3 files changed, 14 insertions(+), 7 deletions(-)
> >>>>create mode 100644 board/qualcomm/default.env
> >>>>
> >>>> diff --git a/board/qualcomm/default.env b/board/qualcomm/default.env
> >>>> new file mode 100644
> >>>> index ..243aede77be7
> >>>> --- /dev/null
> >>>> +++ b/board/qualcomm/default.env
> >>>> @@ -0,0 +1,12 @@
> >>>> +stdin=serial,button-kbd
> >>>> +stdout=serial,vidconsole
> >>>> +stderr=serial,vidconsole
> >>>> +bootfile=/extlinux/extlinux.conf
> >>>
> >>> Is this file used to perform EFI boot or is it redundantly copied from
> >>> somewhere?
> >>
> >> This is here because there's a bunch of codepaths in U-Boot that
> >> implicitly expect the bootfile environment variable to have something
> >> useful in. It stops a whole class of null pointer exceptions.
> >>
> >> extlinux isn't used for EFI booting, but it's supported, and having a
> >> sensible default here is nice-to-have regardless.
> >
> > extlinux is a different boot method as compared to EFI, so it looks
> > confusing to use extlinux as default when we want EFI to be the
> > default. AFAICS, bootfile simply means the file to load and boot which
> > makes it more suitable for Linux image ("Image") to be the default
> > option.
>
> Image? Why not Image.gz, vmlinuz, or vmlinuz.efi?
>
> The value is meaningless, since all this does is stop U-Boot crashing if
> you run some commands without arguments.
>
> The only times I've ever encountered bootfile has been in pxe or
> something related, where extlinux.conf was expected. Obviously this is a
> heavily overloaded variable...
>
> Maybe I should just leave it unset to encourage folks to fix more of
> those unchecked accesses...

That was my original suggestion too, drop it and feel free to keep a
review tag with that.

-Sumit

>
> I don't think changing this to Image would be any more sensible than its
> current value.
> >
> > With that change, feel free to add
> >
> > Reviewed-by: Sumit Garg 
> >
> > -Sumit
> >
> >>
> >> Kind regards,
> >>>
> >>> -Sumit
> >>>
> >>>> +preboot=scsi scan; usb start
> >>>> +fastboot=fastboot -l $fastboot_addr_r usb 0
> >>>> +do_boot=bootefi bootmgr
> >>>> +bootmenu_0=Boot first available device=run do_boot
> >>>> +bootmenu_1=Enable fastboot mode=run fastboot
> >>>> +bootmenu_2=Reset device=reset
> >>>> +menucmd=bootmenu
> >>>> +bootcmd=run do_boot
> >>>> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> >>>> index 80ad3b32e139..a9e3797bb39a 100644
> >>>> --- a/configs/qcom_defconfig
> >>>> +++ b/configs/qcom_defconfig
> >>>> @@ -35,8 +35,10 @@ CONFIG_CMD_BMP=y
> >>>>CONFIG_CMD_LOG=y
> >>>>CONFIG_OF_LIVE=y
> >>>>CONFIG_OF_BOARD_SETUP=y
> >>>>CONFIG_BUTTON_QCOM_PMIC=y
> >>>> +CONFIG_USE_DEFAULT_ENV_FILE=y
> >>>> +CONFIG_DEFAULT_ENV_FILE="board/qualcomm/default.env"
> >>>>CONFIG_CLK=y
> >>>>CONFIG_CLK_QCOM_QCM2290=y
> >>>>CONFIG_CLK_QCOM_QCS404=y
> >>>>CONFIG_CLK_QCOM_SDM845=y
> >>>> diff --git a/include/configs/qcom.h b/include/configs/qcom.h
> >>>> index e50b3bce5cdd..5b5ebbd844df 100644
> >>>> --- a/include/configs/qcom.h
> >>>> +++ b/include/configs/qcom.h
> >>>> @@ -10,12 +10,5 @@
> >>>>#define __CONFIGS_SNAPDRAGON_H
> >>>>
> >>>>#define CFG_SYS_BAUDRATE_TABLE { 115200, 230400, 460800, 921600 }
> >>>>
> >>>> -/* Load addressed are calculated during board_late_init(). See 
> >>>> arm/mach-snapdragon/board.c */
> >>>> -#define CFG_EXTRA_ENV_SETTINGS \
> >>>> -   "stdin=serial,button-kbd\0" \
> >>>> -   "stdout=serial,vidconsole\0"\
> >>>> -   "stderr=serial,vidconsole\0" \
> >>>> -   "bootcmd=bootm $prevbl_initrd_start_addr\0"
> >>>> -
> >>>>#endif
> >>>> --
> >>>> 2.45.0
> >>>>
> >>
> >> --
> >> // Caleb (they/them)
>
> --
> // Caleb (they/them)


Re: [PATCH 2/3] soc: qcom: rpmh and cmd-db drivers

2024-06-21 Thread Sumit Garg
Hi Caleb,

On Mon, 17 Jun 2024 at 14:02, Caleb Connolly  wrote:
>
> Introduce two Qualcomm SoC drivers, the RPMh and cmd-db. RPMh is a the
> name for the second generation Resource Power Management hub on Qualcomm
> SoCs. Most core regulators have to be controlled via this hub.
>
> The cmd-db is a region of memory which contains offsets and data about
> how to communicate with the RPMh.
>
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/soc/Kconfig  |   1 +
>  drivers/soc/Makefile |   1 +
>  drivers/soc/qcom/Kconfig |  25 ++
>  drivers/soc/qcom/Makefile|   4 +
>  drivers/soc/qcom/cmd-db.c| 246 
>  drivers/soc/qcom/rpmh-internal.h | 141 +
>  drivers/soc/qcom/rpmh-rsc.c  | 619 
> +++
>  drivers/soc/qcom/rpmh.c  | 110 +++
>  include/soc/qcom/cmd-db.h|  42 +++
>  include/soc/qcom/rpmh.h  |  29 ++
>  include/soc/qcom/tcs.h   |  78 +
>  11 files changed, 1296 insertions(+)
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 03433bc0e6d2..8ceca0cb1386 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -39,8 +39,9 @@ config SOC_XILINX_VERSAL_NET
>   Enable this option to select SoC device id driver for Xilinx Versal 
> NET.
>   This allows other drivers to verify the SoC familiy & revision using
>   matching SoC attributes.
>
> +source "drivers/soc/qcom/Kconfig"
>  source "drivers/soc/samsung/Kconfig"
>  source "drivers/soc/ti/Kconfig"
>
>  endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 610bf816d40a..c3d484e5bf6c 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -3,8 +3,9 @@
>  # Makefile for the U-Boot SOC specific device drivers.
>
>  obj-$(CONFIG_SOC_SAMSUNG) += samsung/
>  obj-$(CONFIG_SOC_TI) += ti/
> +obj-$(CONFIG_SOC_QCOM) += qcom/
>  obj-$(CONFIG_SOC_DEVICE) += soc-uclass.o
>  obj-$(CONFIG_SOC_DEVICE_TI_K3) += soc_ti_k3.o
>  obj-$(CONFIG_SANDBOX) += soc_sandbox.o
>  obj-$(CONFIG_SOC_XILINX_ZYNQMP) += soc_xilinx_zynqmp.o
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> new file mode 100644
> index ..a0872c5b3c83
> --- /dev/null
> +++ b/drivers/soc/qcom/Kconfig
> @@ -0,0 +1,25 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +menuconfig SOC_QCOM
> +   bool "Qualcomm SOC drivers support"
> +   help
> + Say Y here if you want to enable Qualcomm SOC drivers support.
> +
> +if SOC_QCOM
> +
> +config QCOM_COMMAND_DB
> +   bool "Qualcomm Command DB"
> +   help
> + Command DB queries shared memory by key string for shared system
> + resources. Platform drivers that require to set state of a shared
> + resource on a RPM-hardened platform must use this database to get
> + SoC specific identifier and information for the shared resources.
> +
> +config QCOM_RPMH
> +   bool "Qualcomm RPMh support"
> +   depends on QCOM_COMMAND_DB
> +   help
> + Say y here to support the Qualcomm RPMh (resource peripheral 
> manager)
> + if you need to control regulators on Qualcomm platforms, say y here.
> +
> +endif # SOC_QCOM
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> new file mode 100644
> index ..4fca569cfb77
> --- /dev/null
> +++ b/drivers/soc/qcom/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
> +obj-$(CONFIG_QCOM_RPMH)+= rpmh-rsc.o rpmh.o
> diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
> new file mode 100644
> index ..7bfd72ae2f3f
> --- /dev/null
> +++ b/drivers/soc/qcom/cmd-db.c
> @@ -0,0 +1,246 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2016-2018, 2020, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023, Linaro Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define NUM_PRIORITY   2
> +#define MAX_SLV_ID 8
> +#define SLAVE_ID_MASK  0x7
> +#define SLAVE_ID_SHIFT 16
> +
> +/**
> + * struct entry_header: header for each entry in cmddb
> + *
> + * @id: resource's identifier
> + * @priority: unused
> + * @addr: the address of the resource
> + * @len: length of the data
> + * @offset: offset from :@data_offset, start of the data
> + */
> +struct entry_header {
> +   u8 id[8];
> +   __le32 priority[NUM_PRIORITY];
> +   __le32 addr;
> +   __le16 len;
> +   __le16 offset;
> +};
> +
> +/**
> + * struct rsc_hdr: resource header information
> + *
> + * @slv_id: id for the resource
> + * @header_offset: entry's header at offset from the end of the cmd_db_header
> + * @data_offset: entry's data at offset from the end of the cmd_db_header
> + * @cnt: number of entries for HW type
> + * @version: MSB is major, LSB is minor
> + * @reserved: reserved for 

Re: [PATCH] mach-snapdragon: move default environment to a file

2024-06-21 Thread Sumit Garg
On Fri, 21 Jun 2024 at 13:19, Caleb Connolly  wrote:
>
>
>
> On 21/06/2024 09:35, Sumit Garg wrote:
> > Hi Caleb,
> >
> > On Mon, 17 Jun 2024 at 14:26, Caleb Connolly  
> > wrote:
> >>
> >> Make use of CONFIG_DEFAULT_ENV_FILE and move the default qcom
> >> environment to a file under board/qualcomm.
> >>
> >> This is much cleaner and means we don't need to recompile on changing
> >> the environment.
> >>
> >> Additionally, extend the environment to include a boot menu and
> >> auto-boot using EFI instead of bootm. Since we now support MMC and USB
> >> on most platforms, these are much more useful defaults.
> >>
> >> Signed-off-by: Caleb Connolly 
> >> ---
> >>   board/qualcomm/default.env | 12 
> >>   configs/qcom_defconfig |  2 ++
> >>   include/configs/qcom.h |  7 ---
> >>   3 files changed, 14 insertions(+), 7 deletions(-)
> >>   create mode 100644 board/qualcomm/default.env
> >>
> >> diff --git a/board/qualcomm/default.env b/board/qualcomm/default.env
> >> new file mode 100644
> >> index ..243aede77be7
> >> --- /dev/null
> >> +++ b/board/qualcomm/default.env
> >> @@ -0,0 +1,12 @@
> >> +stdin=serial,button-kbd
> >> +stdout=serial,vidconsole
> >> +stderr=serial,vidconsole
> >> +bootfile=/extlinux/extlinux.conf
> >
> > Is this file used to perform EFI boot or is it redundantly copied from
> > somewhere?
>
> This is here because there's a bunch of codepaths in U-Boot that
> implicitly expect the bootfile environment variable to have something
> useful in. It stops a whole class of null pointer exceptions.
>
> extlinux isn't used for EFI booting, but it's supported, and having a
> sensible default here is nice-to-have regardless.

extlinux is a different boot method as compared to EFI, so it looks
confusing to use extlinux as default when we want EFI to be the
default. AFAICS, bootfile simply means the file to load and boot which
makes it more suitable for Linux image ("Image") to be the default
option.

With that change, feel free to add

Reviewed-by: Sumit Garg 

-Sumit

>
> Kind regards,
> >
> > -Sumit
> >
> >> +preboot=scsi scan; usb start
> >> +fastboot=fastboot -l $fastboot_addr_r usb 0
> >> +do_boot=bootefi bootmgr
> >> +bootmenu_0=Boot first available device=run do_boot
> >> +bootmenu_1=Enable fastboot mode=run fastboot
> >> +bootmenu_2=Reset device=reset
> >> +menucmd=bootmenu
> >> +bootcmd=run do_boot
> >> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> >> index 80ad3b32e139..a9e3797bb39a 100644
> >> --- a/configs/qcom_defconfig
> >> +++ b/configs/qcom_defconfig
> >> @@ -35,8 +35,10 @@ CONFIG_CMD_BMP=y
> >>   CONFIG_CMD_LOG=y
> >>   CONFIG_OF_LIVE=y
> >>   CONFIG_OF_BOARD_SETUP=y
> >>   CONFIG_BUTTON_QCOM_PMIC=y
> >> +CONFIG_USE_DEFAULT_ENV_FILE=y
> >> +CONFIG_DEFAULT_ENV_FILE="board/qualcomm/default.env"
> >>   CONFIG_CLK=y
> >>   CONFIG_CLK_QCOM_QCM2290=y
> >>   CONFIG_CLK_QCOM_QCS404=y
> >>   CONFIG_CLK_QCOM_SDM845=y
> >> diff --git a/include/configs/qcom.h b/include/configs/qcom.h
> >> index e50b3bce5cdd..5b5ebbd844df 100644
> >> --- a/include/configs/qcom.h
> >> +++ b/include/configs/qcom.h
> >> @@ -10,12 +10,5 @@
> >>   #define __CONFIGS_SNAPDRAGON_H
> >>
> >>   #define CFG_SYS_BAUDRATE_TABLE { 115200, 230400, 460800, 921600 }
> >>
> >> -/* Load addressed are calculated during board_late_init(). See 
> >> arm/mach-snapdragon/board.c */
> >> -#define CFG_EXTRA_ENV_SETTINGS \
> >> -   "stdin=serial,button-kbd\0" \
> >> -   "stdout=serial,vidconsole\0"\
> >> -   "stderr=serial,vidconsole\0" \
> >> -   "bootcmd=bootm $prevbl_initrd_start_addr\0"
> >> -
> >>   #endif
> >> --
> >> 2.45.0
> >>
>
> --
> // Caleb (they/them)


Re: [PATCH] mach-snapdragon: move default environment to a file

2024-06-21 Thread Sumit Garg
Hi Caleb,

On Mon, 17 Jun 2024 at 14:26, Caleb Connolly  wrote:
>
> Make use of CONFIG_DEFAULT_ENV_FILE and move the default qcom
> environment to a file under board/qualcomm.
>
> This is much cleaner and means we don't need to recompile on changing
> the environment.
>
> Additionally, extend the environment to include a boot menu and
> auto-boot using EFI instead of bootm. Since we now support MMC and USB
> on most platforms, these are much more useful defaults.
>
> Signed-off-by: Caleb Connolly 
> ---
>  board/qualcomm/default.env | 12 
>  configs/qcom_defconfig |  2 ++
>  include/configs/qcom.h |  7 ---
>  3 files changed, 14 insertions(+), 7 deletions(-)
>  create mode 100644 board/qualcomm/default.env
>
> diff --git a/board/qualcomm/default.env b/board/qualcomm/default.env
> new file mode 100644
> index ..243aede77be7
> --- /dev/null
> +++ b/board/qualcomm/default.env
> @@ -0,0 +1,12 @@
> +stdin=serial,button-kbd
> +stdout=serial,vidconsole
> +stderr=serial,vidconsole
> +bootfile=/extlinux/extlinux.conf

Is this file used to perform EFI boot or is it redundantly copied from
somewhere?

-Sumit

> +preboot=scsi scan; usb start
> +fastboot=fastboot -l $fastboot_addr_r usb 0
> +do_boot=bootefi bootmgr
> +bootmenu_0=Boot first available device=run do_boot
> +bootmenu_1=Enable fastboot mode=run fastboot
> +bootmenu_2=Reset device=reset
> +menucmd=bootmenu
> +bootcmd=run do_boot
> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> index 80ad3b32e139..a9e3797bb39a 100644
> --- a/configs/qcom_defconfig
> +++ b/configs/qcom_defconfig
> @@ -35,8 +35,10 @@ CONFIG_CMD_BMP=y
>  CONFIG_CMD_LOG=y
>  CONFIG_OF_LIVE=y
>  CONFIG_OF_BOARD_SETUP=y
>  CONFIG_BUTTON_QCOM_PMIC=y
> +CONFIG_USE_DEFAULT_ENV_FILE=y
> +CONFIG_DEFAULT_ENV_FILE="board/qualcomm/default.env"
>  CONFIG_CLK=y
>  CONFIG_CLK_QCOM_QCM2290=y
>  CONFIG_CLK_QCOM_QCS404=y
>  CONFIG_CLK_QCOM_SDM845=y
> diff --git a/include/configs/qcom.h b/include/configs/qcom.h
> index e50b3bce5cdd..5b5ebbd844df 100644
> --- a/include/configs/qcom.h
> +++ b/include/configs/qcom.h
> @@ -10,12 +10,5 @@
>  #define __CONFIGS_SNAPDRAGON_H
>
>  #define CFG_SYS_BAUDRATE_TABLE { 115200, 230400, 460800, 921600 }
>
> -/* Load addressed are calculated during board_late_init(). See 
> arm/mach-snapdragon/board.c */
> -#define CFG_EXTRA_ENV_SETTINGS \
> -   "stdin=serial,button-kbd\0" \
> -   "stdout=serial,vidconsole\0"\
> -   "stderr=serial,vidconsole\0" \
> -   "bootcmd=bootm $prevbl_initrd_start_addr\0"
> -
>  #endif
> --
> 2.45.0
>


Re: [PATCH] dt-bindings: imx: Drop redundant imports with dts/upstream

2024-06-19 Thread Sumit Garg
On Wed, 19 Jun 2024 at 18:51, Michael Nazzareno Trimarchi
 wrote:
>
> Hi
>
> On Wed, Jun 19, 2024 at 3:07 PM Sumit Garg  wrote:
> >
> > On Wed, 19 Jun 2024 at 18:26, Adam Ford  wrote:
> > >
> > > On Wed, Jun 19, 2024 at 7:53 AM Sumit Garg  wrote:
> > > >
> > > > Drop redundant header imports with dts/upstream already providing
> > > > updated headers which have been checked to be backwards compatibility.
> > > >
> > > > The imx headers which aren't present in dts/upstream are as follows:
> > > >
> > > > - include/dt-bindings/clock/imxrt1020-clock.h
> > > > - include/dt-bindings/clock/imx8qm-clock.h
> > > > - include/dt-bindings/clock/imxrt1170-clock.h
> > > > - include/dt-bindings/clock/imx8qxp-clock.h
> > > > - include/dt-bindings/memory/imxrt-sdram.h
> > > > - include/dt-bindings/pinctrl/pads-imx8qxp.h
> > > > - include/dt-bindings/pinctrl/pads-imx8qm.h
> > > > - include/dt-bindings/soc/imx8_pd.h
> > > > - include/dt-bindings/soc/imx_rsrc.h
> > > >
> > > > hence these aren't dropped yet but there was an unused header:
> > > >
> > > > - include/dt-bindings/pinctrl/pins-imx8mq.h
> > > >
> > > > which has been dropped as well. There shouldn't be any funtional impact
> > > > with this change but it rather allows iMX platforms to use upstream
> > > > dt-bindings headers in a backwards compatible manner.
> > >
> > > Will this have any impact on board with -u-boot.dtsi files that might
> > > reference these files or will they point to the upstream path?
> > >
> >
> > No it won't have any impact on existing boards, the headers would
> > rather just be included from dts/upstream/include/dt-bindings/
> > instead. The DT files would just be including headers the same way as
> > before: #include . The world build is ongoing
> > here [1] which should be able to justify it.
> >
> > [1] https://github.com/u-boot/u-boot/pull/587
> >
>
> They will point to the upstream part but the fact it's that you can
> test only that they compile ;).

Majority of the headers removed have been compared to be identical and
the rest headers have been checked to be DT ABI compatible with
upstream counterparts. IMHO, that should be enough to believe the
correctness of this patch. If you would like to manually review them
or give this patch a try on a real iMX device then please feel free to
do that.

-Sumit


Re: [PATCH v2] Makefile: Fix include directory for OF_UPSTREAM

2024-06-17 Thread Sumit Garg
Hi Michael,

Sorry for the delayed response as I had some health issues last week.

On Thu, 13 Jun 2024 at 12:44, Michael Nazzareno Trimarchi
 wrote:
>
> Hi Sumit
>
> On Thu, Jun 13, 2024 at 9:02 AM Sumit Garg  wrote:
> >
> > On Mon, 3 Jun 2024 at 20:38, Patrick Barsanti
> >  wrote:
> > >
> > > Always prioritizing u-boot includes causes problems when trying to migrate
> > > boards to OF_UPSTREAM that have different local devicetree files with
> > > respect to the upstream ones, if local DT headers are not dropped.
> > > At the same time if local and upstream files are the same, migrations
> > > can be, and have been, introduced without dropping local DT headers.
> > > This also causes problems whenever upstream DTS and DT headers are 
> > > patched.
> > >
> > > For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
> > > breaks it, as there are some missing defines in a local DT header file
> > > (`imx6ul-clock.h`); the solution would be to drop it, which has not always
> > > been done in previous OF_UPSTREAM migration patches for other boards
> > > because most of the time the two are the same. This solution is also
> > > vulnerable to ABI breakage, although this has not yet happened since the
> > > introduction of OF_UPSTREAM support and is unlikely.
> > >
> > > Maintainers assure backwards compatibility for DT headers when syncing the
> > > upstream folder with the kernel.
> > > The problem is that, at the current state, all boards that have not 
> > > dropped
> > > their local headers when migrating to OF_UPSTREAM will break once the
> > > upstream devicetrees are patched, for example, to use any newly added
> > > define which is not present in the local DT header file, even if those
> > > changes are backwards compatible.
> > >
> > > This patch fixes these problems by prioritizing upstream includes when
> > > `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when it is
> > > not.
> > >
> > > Also in case of ABI breakage in the kernel, keeping redundant header files
> > > (only until strictly necessary, e.g. until all boards including them have
> > > been migrated to OF_UPSTREAM) together with this selective prioritization
> > > of the include folder is a solution for keeping not-yet-migrated boards
> > > from breaking.
> >
> > Let's just not try to make assumptions about DT ABI breakage due to
> > using upstream headers for not-yet-migrated boards but rather talk
> > about some real world examples. Have you come across any DT ABI
> > breakage with usage of upstream headers? The breakage you have
> > reported is due to usage of an old local copy of DT header.
> >
>
> The include priority is broken, and this a Makefile problem anyway.
> This patch fix
> anyway includes priorities.

The include priority only becomes an issue if you want to keep
redundant local copies of DT headers. And I have been advocating to
drop local copies from U-Boot as much as possible. Once we only have
upstream DT headers being used (Qcom platforms can be a good example
here), we don't need to care about trickier priorities.

> The imx6 board migration for us does not work

Patrick did mention here [1] that dropping
include/dt-bindings/clock/imx6ul-clock.h fixes the problem...

>
> > However, if this patch is only needed to address fear of DT ABI
> > breakage (which hasn't happened in the past) then I can live with it
> > such that it can help convince more people for OF_UPSTREAM migration.
> > We can drop local DT headers as and when people feel comfortable with
> > upstream.
>
> It's not abi breakage only but path inclusion order.

...however it's the ABI breakage part that worries Patrick. So if this
patch only solves that worry then I can live with it in the hope that
people will start to gain confidence in DT ABI stability.

[1] 
https://lore.kernel.org/u-boot/cabxfhnfwdd0njpnskaxzxdtg9pdodx5vbhrn9chvmh5xo_7...@mail.gmail.com/

-Sumit


Re: [PATCH v2] Makefile: Fix include directory for OF_UPSTREAM

2024-06-13 Thread Sumit Garg
On Mon, 3 Jun 2024 at 20:38, Patrick Barsanti
 wrote:
>
> Always prioritizing u-boot includes causes problems when trying to migrate
> boards to OF_UPSTREAM that have different local devicetree files with
> respect to the upstream ones, if local DT headers are not dropped.
> At the same time if local and upstream files are the same, migrations
> can be, and have been, introduced without dropping local DT headers.
> This also causes problems whenever upstream DTS and DT headers are patched.
>
> For example, now migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
> breaks it, as there are some missing defines in a local DT header file
> (`imx6ul-clock.h`); the solution would be to drop it, which has not always
> been done in previous OF_UPSTREAM migration patches for other boards
> because most of the time the two are the same. This solution is also
> vulnerable to ABI breakage, although this has not yet happened since the
> introduction of OF_UPSTREAM support and is unlikely.
>
> Maintainers assure backwards compatibility for DT headers when syncing the
> upstream folder with the kernel.
> The problem is that, at the current state, all boards that have not dropped
> their local headers when migrating to OF_UPSTREAM will break once the
> upstream devicetrees are patched, for example, to use any newly added
> define which is not present in the local DT header file, even if those
> changes are backwards compatible.
>
> This patch fixes these problems by prioritizing upstream includes when
> `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when it is
> not.
>
> Also in case of ABI breakage in the kernel, keeping redundant header files
> (only until strictly necessary, e.g. until all boards including them have
> been migrated to OF_UPSTREAM) together with this selective prioritization
> of the include folder is a solution for keeping not-yet-migrated boards
> from breaking.

Let's just not try to make assumptions about DT ABI breakage due to
using upstream headers for not-yet-migrated boards but rather talk
about some real world examples. Have you come across any DT ABI
breakage with usage of upstream headers? The breakage you have
reported is due to usage of an old local copy of DT header.

However, if this patch is only needed to address fear of DT ABI
breakage (which hasn't happened in the past) then I can live with it
such that it can help convince more people for OF_UPSTREAM migration.
We can drop local DT headers as and when people feel comfortable with
upstream.

-Sumit

>
> Link: 
> https://lore.kernel.org/u-boot/20240528084224.113385-1-patrick.barsa...@amarulasolutions.com/
> Signed-off-by: Patrick Barsanti 
> Tested-by: Michael Trimarchi 
> ---
>
> Changes in v2:
> - Reword and correct the commit message following the discussion
> with Sumit, per Michael's suggestion.
>
>  Makefile | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 79b28c2d81..899ae664ca 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
>
>  # Use UBOOTINCLUDE when you must reference the include/ directory.
>  # Needed to be compatible with the O= option
> +ifeq ($(CONFIG_OF_UPSTREAM),y)
> +UBOOTINCLUDE:= \
> +   -I$(srctree)/dts/upstream/include \
> +   -Iinclude \
> +   $(if $(KBUILD_SRC), -I$(srctree)/include) \
> +   $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \
> +   $(if $(CONFIG_HAS_THUMB2), \
> +   $(if $(CONFIG_CPU_V7M), \
> +   -I$(srctree)/arch/arm/thumb1/include), \
> +   -I$(srctree)/arch/arm/thumb1/include)) \
> +   -I$(srctree)/arch/$(ARCH)/include \
> +   -include $(srctree)/include/linux/kconfig.h
> +else
>  UBOOTINCLUDE:= \
> -Iinclude \
> $(if $(KBUILD_SRC), -I$(srctree)/include) \
> @@ -837,6 +850,7 @@ UBOOTINCLUDE:= \
> -I$(srctree)/arch/$(ARCH)/include \
> -include $(srctree)/include/linux/kconfig.h \
> -I$(srctree)/dts/upstream/include
> +endif
>
>  NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
>
> --
> 2.45.1
>


Re: [PATCH v3 0/8] qcom: implement capsule updates

2024-06-06 Thread Sumit Garg
On Wed, 5 Jun 2024 at 18:12, Caleb Connolly  wrote:
>
> Hi Sumit,
>
> On 05/06/2024 07:31, Sumit Garg wrote:
> > Hi Caleb,
> >
> > On Mon, 3 Jun 2024 at 18:19, Caleb Connolly  
> > wrote:
> >>
> >> Hook up support for capsule updates loaded from disk on Qualcomm
> >> platforms.
> >>
> >> Most Qualcomm devices have an A/B partition layout, with most partitions
> >> duplicated. The metadata on which slot is active is stored in the GPT
> >> headers in the vendor-specific attribute bits of each partition.
> >
> > It's good to see capsule updates support coming up for Qualcomm
> > platforms. AFAICS, with this series we only update U-Boot on the
> > current active partition. IOW, real A/B support is still not
> > supported. Do you think it is possible for U-Boot to update metadata
> > in GPT headers and for proprietary bootloaders to pick up the U-Boot
> > from the updated partition?
>
> Yes this would be possible, I have some WIP patches to let us modify the
> slot attribute bits and write back the header.

Nice to hear that possibility.

>
> The reason I haven't implement A/B is because we don't support it from
> the OS level on any of the boards I work on. We often patch ABL to
> disable or skip the slot logic and flash a partition table without
> slots. It also unlocks a bunch of additional complexity...

Please have a look at an alternative FWU Multi Bank Updates [1].
AFAIK, the UEFI capsules updates feature from the OS point of view
remains transparent. It's more about how those capsules are
interpreted with the logic to update the inactive partition and
metadata such that subsequent boot uses the updated firmware.

[1] https://docs.u-boot.org/en/latest/develop/uefi/fwu_updates.html

>
> This isn't super high on my todo list but I'd be happy to help if
> someone wants to enable this functionality. We'd need:
>
> 1. Upstream support for modifying the GPT (see my PoC at [1] and [2]).
> 2. Logic to configure flashing the active or inactive slot
>
> This logic would have to run after the capsule update, I don't know if
> there is currently a way to add a callback after the update.
>
> If we enable updating other images (like XBL, hyp, tz, etc), we would
> need to either agree that a capsule update would have to update ALL
> partitions, or implement logic to copy over partitions that weren't
> flashed to the other slot.

I would be interested to see how we can plug Qcom specific pieces
underneath in order to have multi bank updates. However, this patchset
is still usable in its current form. We can later add the real A/B
functionality.

Apart from patch #4 where we are still discussing the finer details,
feel free to add:

Acked-by: Sumit Garg 

-Sumit

>
> [1]:
> https://git.codelinaro.org/linaro/qcomlt/u-boot/-/commit/34d3de6f79550527746303e0bf6337fa37e31fe5
>
> [2]:
> https://git.codelinaro.org/linaro/qcomlt/u-boot/-/commit/656d9e816bef85e586460a999cc7874255be9f1d


Re: [PATCH v3 4/8] mach-snapdragon: implement capsule update support

2024-06-06 Thread Sumit Garg
On Wed, 5 Jun 2024 at 18:03, Caleb Connolly  wrote:
>
> Hi Sumit,
> >> +/**
> >> + * qcom_configure_capsule_updates() - Configure the DFU string for 
> >> capsule updates
> >> + *
> >> + * U-Boot is flashed to the boot partition on Qualcomm boards. In most 
> >> cases there
> >> + * are two boot partitions, boot_a and boot_b. As we don't currently 
> >> support doing
> >> + * full A/B updates, we only support updating the currently active boot 
> >> partition.
> >> + *
> >> + * So we need to find the current slot suffix and the associated boot 
> >> partition.
> >> + * We do this by looking for the boot partition that has the 'active' 
> >> flag set
> >> + * in the GPT partition vendor attribute bits.
> >> + */
> >> +void qcom_configure_capsule_updates(void)
> >> +{
> >> +   struct blk_desc *desc;
> >> +   int ret = 0, partnum = -1, devnum;
> >> +   static char dfu_string[32] = { 0 };
> >> +   char name[32]; /* GPT partition name */
> >> +   char *partname = "boot";
> >> +   struct udevice *dev = NULL;
> >> +
> >> +   /*
> >> +* There is currently no good way to check how U-Boot is booting, 
> >> but we have
> >> +* a few hueristics, like here checking if our DTB has a 
> >> kaslr-seed specified
> >> +* will tell us if we were chainloaded by another bootloader.
> >> +* FIXME: we should do this check once and use some proper API to 
> >> expose the data.
> >
> > If U-Boot is built with LINUX_KERNEL_IMAGE_HEADER enabled then we
> > should know that U-Boot is built as a replacement of Linux kernel and
> > hence chainloaded. Isn't that what you need here?
>
> Not necessarily, you can build with LINUX_KERNEL_IMAGE_HEADER and then
> pack U-Boot into XBL or flash it to hyp and it will still run (the
> kernel header is specifically written to behave like a nop slide). So we
> can't rely on this.
> >

Yeah you can build it in whatever form downstream and run as a NOP too
but I don't think we support any such combination in upstream U-Boot,
right? We should let people know that LINUX_KERNEL_IMAGE_HEADER should
only be enabled if the U-Boot image is flashed into the boot partition
as a replacement for Linux kernel image. BTW, isn't that the real
meaning for that config option? IMHO, the current DT check you have
implemented is implicit and I am unsure if we can reliably depend upon
it.

-Sumit


Re: [PATCH v4 00/10] add ArmSoM Sige7 Rk3588 board

2024-06-06 Thread Sumit Garg
Hi Jianfeng,

On Tue, 28 May 2024 at 22:35, Jianfeng Liu  wrote:
>
> This series also introduces dts commits of rk3588s.dtsi and rk3588.dtsi
> from v6.10-rc1-dts.
> Then dts of ArmSoM Sige7 is picked from upstream.
> I also remove obsolete usb3 nodes of rk3588-u-boot.dtsi and
> rk3588-u-boot.dtsi.
>
> Changes in v4:
> - Pick all commits of rk3588s.dtsi and rk3588.dtsi from v6.10-rc1-dts
> - Remove obsolete USB3 DRD nodes in u-boot.dtsi of rk3588s/rk3588
> - Remove sdhci and usb nodes from rk3588-armsom-sige7-u-boot.dtsi
>
> Changes in v3:
> - Use update-dts-subtree.sh to pick upstream dts
>
> Changes in v2:
> - Fix alphabetical order of MAINTAINERS
> - Use arch/arm/dts/rk3588-armsom-sige7* in board MAINTAINERS
> - Remove spi flash related config
> - Move kernel dts to dts/upstream/src/arm64/rockchip/
>
> Boris Brezillon (1):
>   arm64: dts: rockchip: Add rk3588 GPU node
>
> Diederik de Haas (1):
>   arm64: dts: rockchip: Fix ordering of nodes on rk3588s
>
> Jianfeng Liu (3):
>   arm64: dts: rockchip: Add ArmSom Sige7 board
>   rockchip: rk3588: Remove USB3 DRD nodes in u-boot.dtsi
>   board: rockchip: add ArmSoM Sige7 Rk3588 board
>
> Niklas Cassel (1):
>   arm64: dts: rockchip: add rk3588 pcie and php IOMMUs
>
> Sebastian Reichel (4):
>   arm64: dts: rockchip: fix usb2phy nodename for rk3588
>   arm64: dts: rockchip: reorder usb2phy properties for rk3588
>   arm64: dts: rockchip: add USBDP phys on rk3588
>   arm64: dts: rockchip: add USB3 DRD controllers on rk3588
>

Nice to see cherry pick from subtree worked as expected for you.

FWIW, for the series:

Acked-by: Sumit Garg 

-Sumit

>  MAINTAINERS   |   1 +
>  arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi  |   6 +
>  arch/arm/dts/rk3588-u-boot.dtsi   |  74 --
>  arch/arm/dts/rk3588s-u-boot.dtsi  |  85 ---
>  arch/arm/mach-rockchip/rk3588/Kconfig |  26 +
>  board/armsom/sige7-rk3588/Kconfig |  12 +
>  board/armsom/sige7-rk3588/MAINTAINERS |   7 +
>  configs/sige7-rk3588_defconfig|  93 +++
>  doc/board/rockchip/rockchip.rst   |   1 +
>  .../arm64/rockchip/rk3588-armsom-sige7.dts| 721 ++
>  dts/upstream/src/arm64/rockchip/rk3588.dtsi   |  72 ++
>  dts/upstream/src/arm64/rockchip/rk3588s.dtsi  | 377 ++---
>  include/configs/sige7-rk3588.h|  15 +
>  13 files changed, 1225 insertions(+), 265 deletions(-)
>  create mode 100644 arch/arm/dts/rk3588-armsom-sige7-u-boot.dtsi
>  create mode 100644 board/armsom/sige7-rk3588/Kconfig
>  create mode 100644 board/armsom/sige7-rk3588/MAINTAINERS
>  create mode 100644 configs/sige7-rk3588_defconfig
>  create mode 100644 dts/upstream/src/arm64/rockchip/rk3588-armsom-sige7.dts
>  create mode 100644 include/configs/sige7-rk3588.h
>
> --
> 2.34.1
>


Re: [PATCH v3 0/8] qcom: implement capsule updates

2024-06-04 Thread Sumit Garg
Hi Caleb,

On Mon, 3 Jun 2024 at 18:19, Caleb Connolly  wrote:
>
> Hook up support for capsule updates loaded from disk on Qualcomm
> platforms.
>
> Most Qualcomm devices have an A/B partition layout, with most partitions
> duplicated. The metadata on which slot is active is stored in the GPT
> headers in the vendor-specific attribute bits of each partition.

It's good to see capsule updates support coming up for Qualcomm
platforms. AFAICS, with this series we only update U-Boot on the
current active partition. IOW, real A/B support is still not
supported. Do you think it is possible for U-Boot to update metadata
in GPT headers and for proprietary bootloaders to pick up the U-Boot
from the updated partition?

-Sumit

>
> Add support for reading this attributes via the disk_partition struct
> and using them to determine which boot partition U-Boot is flashed to
> and generate the appropriate DFU string.
>
> This logic is gated behind a check to ensure that U-Boot is actually
> being chainloaded and not run via some other mechanism.
>
> SCSI support for most Qualcomm platforms is not yet enabled upstream,
> but will follow in future patches.
>
> This series enables capsule updates on the RB2, however [1] is required
> for it to work properly (as otherwise MMC won't be available).
>
> [1]: 
> https://lore.kernel.org/u-boot/20240527-b4-clk-stub-v2-0-29013855e...@linaro.org/
>
> To: Tom Rini 
> To: Simon Glass 
> To: Lukasz Majewski 
> To: Mattijs Korpershoek 
> To: Caleb Connolly 
> To: Neil Armstrong 
> To: Sumit Garg 
> Cc: Ilias Apalodimas 
> Cc: u-boot@lists.denx.de
> Cc: u-boot-q...@groups.io
>
> Changes in v3:
> - Address comments in scsi dfu support
> - enable CONFIG_DFU_SCSI for qcom
> - Link to v2: 
> https://lore.kernel.org/r/20240527-b4-qcom-capsule-updates-v2-0-47583d7ad...@linaro.org
>
> Changes in v2:
> - Add qcom capsule update support patches
> - Link to v1: 
> https://lore.kernel.org/r/20240409-b4-dfu-scsi-v1-0-3e1441a60...@linaro.org
>
> ---
> Caleb Connolly (8):
>   dfu: add scsi backend
>   disk: expose partition type flags
>   mmc: msm_sdhci: work around a bug when writing
>   mach-snapdragon: implement capsule update support
>   qcom_defconfig: savedefconfig
>   mach-snapdragon: use SYSRESET_PSCI
>   mach-snapdragon: bump up heap size
>   qcom_defconfig: enable capsule update support
>
>  arch/arm/Kconfig  |   2 +
>  arch/arm/mach-snapdragon/Kconfig  |   3 +
>  arch/arm/mach-snapdragon/Makefile |   1 +
>  arch/arm/mach-snapdragon/board.c  |   8 +-
>  arch/arm/mach-snapdragon/capsule_update.c | 147 ++
>  arch/arm/mach-snapdragon/qcom-priv.h  |   6 +
>  configs/qcom_defconfig|  19 +-
>  disk/part_efi.c   |   1 +
>  doc/usage/dfu.rst |  32 +++
>  drivers/dfu/Kconfig   |   7 +
>  drivers/dfu/Makefile  |   1 +
>  drivers/dfu/dfu.c |   5 +-
>  drivers/dfu/dfu_scsi.c| 435 
> ++
>  drivers/mmc/msm_sdhci.c   |   7 +
>  include/configs/qcom.h|   5 +
>  include/dfu.h |  26 ++
>  include/part.h|   1 +
>  17 files changed, 695 insertions(+), 11 deletions(-)
> ---
> change-id: 20240523-b4-qcom-capsule-updates-ea2e4f8f0ff0
> base-commit: 5d8881a0801241d68701e8644d495f1d535506f0
>
> // Caleb (they/them)
>


Re: [PATCH v3 4/8] mach-snapdragon: implement capsule update support

2024-06-04 Thread Sumit Garg
Hi Caleb,

On Mon, 3 Jun 2024 at 18:19, Caleb Connolly  wrote:
>
> Qualcomm boards flash U-Boot to the boot partition, implement support
> for determining which slot U-Boot is running from and finding the
> correct boot partition for that slot and configuring the appropriate DFU
> string.
>
> For now this only supports boards with SCSI/UFS storage where U-Boot is
> flashed to the boot partition, and only U-Boot itself is updated. In the
> future we may also support updating additional firmware components (tz,
> hyp, xbl) as well as having U-Boot installed to other partitions (e.g.
> as a first-stage bootloader).
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/mach-snapdragon/Makefile |   1 +
>  arch/arm/mach-snapdragon/board.c  |   3 +
>  arch/arm/mach-snapdragon/capsule_update.c | 147 
> ++
>  arch/arm/mach-snapdragon/qcom-priv.h  |   6 ++
>  include/configs/qcom.h|   5 +
>  5 files changed, 162 insertions(+)
>
> diff --git a/arch/arm/mach-snapdragon/Makefile 
> b/arch/arm/mach-snapdragon/Makefile
> index 7a4495c8108f..343e825c6fdd 100644
> --- a/arch/arm/mach-snapdragon/Makefile
> +++ b/arch/arm/mach-snapdragon/Makefile
> @@ -2,5 +2,6 @@
>  #
>  # (C) Copyright 2015 Mateusz Kulikowski 
>
>  obj-y += board.o
> +obj-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += capsule_update.o
>  obj-$(CONFIG_OF_LIVE) += of_fixup.o
> diff --git a/arch/arm/mach-snapdragon/board.c 
> b/arch/arm/mach-snapdragon/board.c
> index b439a19ec7eb..c4a3394706e6 100644
> --- a/arch/arm/mach-snapdragon/board.c
> +++ b/arch/arm/mach-snapdragon/board.c
> @@ -299,8 +299,11 @@ int board_late_init(void)
>
> configure_env();
> qcom_late_init();
>
> +   /* Configure the dfu_string for capsule updates */
> +   qcom_configure_capsule_updates();
> +
> return 0;
>  }
>
>  static void build_mem_map(void)
> diff --git a/arch/arm/mach-snapdragon/capsule_update.c 
> b/arch/arm/mach-snapdragon/capsule_update.c
> new file mode 100644
> index ..505f5bf5ae07
> --- /dev/null
> +++ b/arch/arm/mach-snapdragon/capsule_update.c
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Common initialisation for Qualcomm Snapdragon boards.
> + *
> + * Copyright (c) 2024 Linaro Ltd.
> + * Author: Caleb Connolly 
> + */
> +
> +#define pr_fmt(fmt) "QCOM-FMP: " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "qcom-priv.h"
> +
> +struct efi_fw_image fw_images[] = {
> +   {
> +   .image_type_id = QUALCOMM_UBOOT_BOOT_IMAGE_GUID,
> +   .fw_name = u"QUALCOMM-UBOOT",
> +   .image_index = 1,
> +   },
> +};
> +
> +struct efi_capsule_update_info update_info = {
> +   /* Filled in by configure_dfu_string() */
> +   .dfu_string = NULL,
> +   .num_images = ARRAY_SIZE(fw_images),
> +   .images = fw_images,
> +};
> +
> +/* LSB first */
> +struct part_slot_status {
> +   u16: 2;
> +   u16 active : 1;
> +   u16: 3;
> +   u16 successful : 1;
> +   u16 unbootable : 1;
> +   u16 tries_remaining : 4;
> +};
> +
> +static int find_boot_partition(const char *partname, struct blk_desc 
> *blk_dev, char *name)
> +{
> +   int ret;
> +   int partnum;
> +   struct disk_partition info;
> +   struct part_slot_status *slot_status;
> +
> +   for (partnum = 1;; partnum++) {
> +   ret = part_get_info(blk_dev, partnum, );
> +   if (ret)
> +   return ret;
> +
> +   slot_status = (struct part_slot_status *)_flags;
> +   log_io("%16s: Active: %1d, Successful: %1d, Unbootable: %1d, 
> Tries left: %1d\n",
> +  info.name, slot_status->active,
> +  slot_status->successful, slot_status->unbootable,
> +  slot_status->tries_remaining);
> +   if (!strncmp(info.name, partname, strlen(partname)) && 
> slot_status->active) {
> +   log_debug("Found active %s partition: '%s'!\n", 
> partname, info.name);
> +   strlcpy(name, info.name, sizeof(info.name));
> +   return partnum;
> +   }
> +   }
> +
> +   return -1;
> +}
> +
> +/**
> + * qcom_configure_capsule_updates() - Configure the DFU string for capsule 
> updates
> + *
> + * U-Boot is flashed to the boot partition on Qualcomm boards. In most cases 
> there
> + * are two boot partitions, boot_a and boot_b. As we don't currently support 
> doing
> + * full A/B updates, we only support updating the currently active boot 
> partition.
> + *
> + * So we need to find the current slot suffix and the associated boot 
> partition.
> + * We do this by looking for the boot partition that has the 'active' flag 
> set
> + * in the GPT partition vendor attribute bits.
> + */
> +void qcom_configure_capsule_updates(void)
> +{
> +   struct blk_desc *desc;
> 

Re: [PATCH] Makefile: Fix include directory for OF_UPSTREAM

2024-05-30 Thread Sumit Garg
On Thu, 30 May 2024 at 14:43, Patrick Barsanti
 wrote:
>
> Hi Sumit,
>
> On Wed, 29 May 2024 at 14:00, Sumit Garg  wrote:
>>
>> On Wed, 29 May 2024 at 14:45, Patrick Barsanti
>>  wrote:
>> >
>> > Hi Sumit,
>> >
>> > On Wed, 29 May 2024 at 08:57, Sumit Garg  wrote:
>> >>
>> >> Hi Patrick,
>> >>
>> >> On Tue, 28 May 2024 at 14:16, Patrick Barsanti
>> >>  wrote:
>> >> >
>> >> > Always prioritizing u-boot includes causes problems when trying to
>> >> > migrate boards to OF_UPSTREAM that have divergent devicetree files with
>> >> > respect to the upstream ones.
>> >> >
>> >> > For example, migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
>> >> > breaks it, as there are some missing defines in the local dtsi file;
>> >> > the solutions would be to either patch it, which defeats the purpose of
>> >> > OF_UPSTREAM, or delete it entirely. This last option would then break 
>> >> > all
>> >> > the other boards which have not yet been migrated to OF_UPSTREAM.
>> >>
>> >> Can you elaborate more here regarding which dt-bindings headers
>> >> conflict? Also, is it only the DTS files consumer for those headers or
>> >> there are U-Boot drivers depending on them too?
>> >>
>> >> -Sumit
>> >
>> >
>> > Sorry, I think I have worded my commit message wrong. I should
>> > have used differ instead of diverge, which is slightly misleading.
>> >
>> > The specific case I am talking about can be found in:
>> > include/dt-bindings/clock/imx6ul-clock.h
>> > dts/upstream/include/dt-bindings/clock/imx6ul-clock.h
>> >
>> > The local header is missing the last commit from the kernel, which is
>> > 4e197ee880c2 ("clk: imx6ul: add ethernet refclock mux support").
>> > This added some new defines, which are not present in the u-boot
>> > header.
>> > Following this commit, the `imx6ul.dtsi` was patched in the kernel to
>> > use one of the new defines.
>> >
>> > Because of this, at the current state, migrating a board which is
>> > somehow based on `imx6ul.dtsi` will give a dtc error given by a value
>> > being used in the upstream dtsi which is not defined in the local
>> > header, because local includes always have priority with respect
>> > to upstream ones even when setting OF_UPSTREAM.
>>
>> So you should just drop the local DT bindings header:
>> include/dt-bindings/clock/imx6ul-clock.h and that should resolve the
>> problem for you, right?
>
>
> Yes, that indeed solves my problem.
> But if I drop it, I will force all other boards which are not yet
> migrated to OF_UPSTREAM and include `imx6ul.dtsi` to
> use the upstream header instead of the local one.
> I did not feel comfortable in doing so, because if any change is made
> to the upstream header in the future which is somehow not backwards
> compatible, then all boards which are still not using OF_UPSTREAM
> would not compile.

DT headers backwards compatibility is something that upstream DT
maintainers assure us about. And we try to closely monitor any DT ABI
breakage while syncing upstream DT. Till now after we added
OF_UPSTREAM support, fortunately there hasn't been any DT ABI breakage
reports. So we should switch to upstream DT headers wherever we can
and drop any redundant local DT headers. Migration to OF_UPSTREAM can
surely be the next step but we want to encourage more and more code
reuse from upstream DT sources.

>
> I also thought this would not be limited to the single header file which
> caused my problem. I imagine there would be other cases of local
> headers which are missing one or more commits from mainline kernel
> and cause the same type of problem when moving to OF_UPSTREAM.

The redundant local DT headers should be dropped wherever we can.
Adding further defines or new clocks in your case isn't going to break
backwards compatibility but rather dropping any existing clock defines
would be a DT ABI breakage.

>
> The opposite problem also exists.
> For example:
> 675575880f ("phycore-am64x: Migrate to OF_UPSTREAM")
> does not drop include/dt-bindings/net/ti-dp83867.h, and I think the
> migration worked properly only because at the moment there is no
> difference between local and upstream headers.

That's a leftover from migration, feel free to propose a patch to drop it.

> If and when the upstream headers and devicetrees will be patched,
> this will cause problems, because the local include 

Re: [PATCH] Makefile: Fix include directory for OF_UPSTREAM

2024-05-29 Thread Sumit Garg
On Wed, 29 May 2024 at 14:45, Patrick Barsanti
 wrote:
>
> Hi Sumit,
>
> On Wed, 29 May 2024 at 08:57, Sumit Garg  wrote:
>>
>> Hi Patrick,
>>
>> On Tue, 28 May 2024 at 14:16, Patrick Barsanti
>>  wrote:
>> >
>> > Always prioritizing u-boot includes causes problems when trying to
>> > migrate boards to OF_UPSTREAM that have divergent devicetree files with
>> > respect to the upstream ones.
>> >
>> > For example, migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
>> > breaks it, as there are some missing defines in the local dtsi file;
>> > the solutions would be to either patch it, which defeats the purpose of
>> > OF_UPSTREAM, or delete it entirely. This last option would then break all
>> > the other boards which have not yet been migrated to OF_UPSTREAM.
>>
>> Can you elaborate more here regarding which dt-bindings headers
>> conflict? Also, is it only the DTS files consumer for those headers or
>> there are U-Boot drivers depending on them too?
>>
>> -Sumit
>
>
> Sorry, I think I have worded my commit message wrong. I should
> have used differ instead of diverge, which is slightly misleading.
>
> The specific case I am talking about can be found in:
> include/dt-bindings/clock/imx6ul-clock.h
> dts/upstream/include/dt-bindings/clock/imx6ul-clock.h
>
> The local header is missing the last commit from the kernel, which is
> 4e197ee880c2 ("clk: imx6ul: add ethernet refclock mux support").
> This added some new defines, which are not present in the u-boot
> header.
> Following this commit, the `imx6ul.dtsi` was patched in the kernel to
> use one of the new defines.
>
> Because of this, at the current state, migrating a board which is
> somehow based on `imx6ul.dtsi` will give a dtc error given by a value
> being used in the upstream dtsi which is not defined in the local
> header, because local includes always have priority with respect
> to upstream ones even when setting OF_UPSTREAM.

So you should just drop the local DT bindings header:
include/dt-bindings/clock/imx6ul-clock.h and that should resolve the
problem for you, right?

-Sumit

>
> Regards,
> Patrick
>
>>
>> >
>> > The opposite problem also exists: by always prioritizing upstream
>> > includes, if changes are made in the kernel headers and devicetree
>> > files that are not backwards compatible, again all boards which have not
>> > been migrated to OF_UPSTREAM will break.
>> >
>> > This patch fixes this problem by prioritizing upstream includes when
>> > `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when
>> > it is not.
>> >
>> > Signed-off-by: Patrick Barsanti 
>> > ---
>> >  Makefile | 14 ++
>> >  1 file changed, 14 insertions(+)
>> >
>> > diff --git a/Makefile b/Makefile
>> > index 79b28c2d81..899ae664ca 100644
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
>> >
>> >  # Use UBOOTINCLUDE when you must reference the include/ directory.
>> >  # Needed to be compatible with the O= option
>> > +ifeq ($(CONFIG_OF_UPSTREAM),y)
>> > +UBOOTINCLUDE:= \
>> > +   -I$(srctree)/dts/upstream/include \
>> > +   -Iinclude \
>> > +   $(if $(KBUILD_SRC), -I$(srctree)/include) \
>> > +   $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \
>> > +   $(if $(CONFIG_HAS_THUMB2), \
>> > +   $(if $(CONFIG_CPU_V7M), \
>> > +   -I$(srctree)/arch/arm/thumb1/include), \
>> > +   -I$(srctree)/arch/arm/thumb1/include)) \
>> > +   -I$(srctree)/arch/$(ARCH)/include \
>> > +   -include $(srctree)/include/linux/kconfig.h
>> > +else
>> >  UBOOTINCLUDE:= \
>> > -Iinclude \
>> > $(if $(KBUILD_SRC), -I$(srctree)/include) \
>> > @@ -837,6 +850,7 @@ UBOOTINCLUDE:= \
>> > -I$(srctree)/arch/$(ARCH)/include \
>> > -include $(srctree)/include/linux/kconfig.h \
>> > -I$(srctree)/dts/upstream/include
>> > +endif
>> >
>> >  NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) 
>> > -print-file-name=include)
>> >
>> > --
>> > 2.43.0
>> >


Re: [PATCH] Makefile: Fix include directory for OF_UPSTREAM

2024-05-29 Thread Sumit Garg
Hi Patrick,

On Tue, 28 May 2024 at 14:16, Patrick Barsanti
 wrote:
>
> Always prioritizing u-boot includes causes problems when trying to
> migrate boards to OF_UPSTREAM that have divergent devicetree files with
> respect to the upstream ones.
>
> For example, migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
> breaks it, as there are some missing defines in the local dtsi file;
> the solutions would be to either patch it, which defeats the purpose of
> OF_UPSTREAM, or delete it entirely. This last option would then break all
> the other boards which have not yet been migrated to OF_UPSTREAM.

Can you elaborate more here regarding which dt-bindings headers
conflict? Also, is it only the DTS files consumer for those headers or
there are U-Boot drivers depending on them too?

-Sumit

>
> The opposite problem also exists: by always prioritizing upstream
> includes, if changes are made in the kernel headers and devicetree
> files that are not backwards compatible, again all boards which have not
> been migrated to OF_UPSTREAM will break.
>
> This patch fixes this problem by prioritizing upstream includes when
> `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when
> it is not.
>
> Signed-off-by: Patrick Barsanti 
> ---
>  Makefile | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 79b28c2d81..899ae664ca 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
>
>  # Use UBOOTINCLUDE when you must reference the include/ directory.
>  # Needed to be compatible with the O= option
> +ifeq ($(CONFIG_OF_UPSTREAM),y)
> +UBOOTINCLUDE:= \
> +   -I$(srctree)/dts/upstream/include \
> +   -Iinclude \
> +   $(if $(KBUILD_SRC), -I$(srctree)/include) \
> +   $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \
> +   $(if $(CONFIG_HAS_THUMB2), \
> +   $(if $(CONFIG_CPU_V7M), \
> +   -I$(srctree)/arch/arm/thumb1/include), \
> +   -I$(srctree)/arch/arm/thumb1/include)) \
> +   -I$(srctree)/arch/$(ARCH)/include \
> +   -include $(srctree)/include/linux/kconfig.h
> +else
>  UBOOTINCLUDE:= \
> -Iinclude \
> $(if $(KBUILD_SRC), -I$(srctree)/include) \
> @@ -837,6 +850,7 @@ UBOOTINCLUDE:= \
> -I$(srctree)/arch/$(ARCH)/include \
> -include $(srctree)/include/linux/kconfig.h \
> -I$(srctree)/dts/upstream/include
> +endif
>
>  NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
>
> --
> 2.43.0
>


Re: [PATCH 5/5] pinctrl: qcom: sm8650: add special pins pins configuration data

2024-05-29 Thread Sumit Garg
On Tue, 28 May 2024 at 14:02, Neil Armstrong  wrote:
>
> Add the special pins configuration data to allow setup the bias
> of the UFS and SDCard pins on the SM8650 SoC.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/pinctrl/qcom/pinctrl-sm8650.c | 42 
> ---
>  1 file changed, 34 insertions(+), 8 deletions(-)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/drivers/pinctrl/qcom/pinctrl-sm8650.c 
> b/drivers/pinctrl/qcom/pinctrl-sm8650.c
> index d6cc1bbdda8..58fc94e71ac 100644
> --- a/drivers/pinctrl/qcom/pinctrl-sm8650.c
> +++ b/drivers/pinctrl/qcom/pinctrl-sm8650.c
> @@ -18,6 +18,37 @@ static const struct pinctrl_function 
> msm_pinctrl_functions[] = {
> {"gpio", 0},
>  };
>
> +#define SDC_QDSD_PINGROUP(pg_name, ctl, pull, drv) \
> +   {   \
> +   .name = pg_name,\
> +   .ctl_reg = ctl, \
> +   .io_reg = 0,\
> +   .pull_bit = pull,   \
> +   .drv_bit = drv, \
> +   .oe_bit = -1,   \
> +   .in_bit = -1,   \
> +   .out_bit = -1,  \
> +   }
> +
> +#define UFS_RESET(pg_name, ctl, io)\
> +   {   \
> +   .name = pg_name,\
> +   .ctl_reg = ctl, \
> +   .io_reg = io,   \
> +   .pull_bit = 3,  \
> +   .drv_bit = 0,   \
> +   .oe_bit = -1,   \
> +   .in_bit = -1,   \
> +   .out_bit = 0,   \
> +   }
> +
> +static const struct msm_special_pin_data msm_special_pins_data[] = {
> +   [0] = UFS_RESET("ufs_reset", 0xde004, 0xdf000),
> +   [1] = SDC_QDSD_PINGROUP("sdc2_clk", 0xd6000, 14, 6),
> +   [2] = SDC_QDSD_PINGROUP("sdc2_cmd", 0xd6000, 11, 3),
> +   [3] = SDC_QDSD_PINGROUP("sdc2_data", 0xd6000, 9, 0),
> +};
> +
>  static const char *sm8650_get_function_name(struct udevice *dev,
>  unsigned int selector)
>  {
> @@ -27,15 +58,9 @@ static const char *sm8650_get_function_name(struct udevice 
> *dev,
>  static const char *sm8650_get_pin_name(struct udevice *dev,
> unsigned int selector)
>  {
> -   static const char *special_pins_names[] = {
> -   "ufs_reset",
> -   "sdc2_clk",
> -   "sdc2_cmd",
> -   "sdc2_data",
> -   };
> -
> if (selector >= 210 && selector <= 213)
> -   snprintf(pin_name, MAX_PIN_NAME_LEN, 
> special_pins_names[selector - 210]);
> +   snprintf(pin_name, MAX_PIN_NAME_LEN,
> +msm_special_pins_data[selector - 210].name);
> else
> snprintf(pin_name, MAX_PIN_NAME_LEN, "gpio%u", selector);
>
> @@ -52,6 +77,7 @@ static struct msm_pinctrl_data sm8650_data = {
> .pin_data = {
> .pin_count = 214,
> .special_pins_start = 210,
> +   .special_pins_data = msm_special_pins_data,
> },
> .functions_count = ARRAY_SIZE(msm_pinctrl_functions),
> .get_function_name = sm8650_get_function_name,
>
> --
> 2.34.1
>


Re: [PATCH 4/5] pinctrl: qcom: sm8550: add special pins pins configuration data

2024-05-29 Thread Sumit Garg
On Tue, 28 May 2024 at 14:02, Neil Armstrong  wrote:
>
> Add the special pins configuration data to allow setup the bias
> of the UFS and SDCard pins on the SM8550 SoC.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/pinctrl/qcom/pinctrl-sm8550.c | 42 
> ---
>  1 file changed, 34 insertions(+), 8 deletions(-)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/drivers/pinctrl/qcom/pinctrl-sm8550.c 
> b/drivers/pinctrl/qcom/pinctrl-sm8550.c
> index 7265cb73404..c65dfe0435e 100644
> --- a/drivers/pinctrl/qcom/pinctrl-sm8550.c
> +++ b/drivers/pinctrl/qcom/pinctrl-sm8550.c
> @@ -18,6 +18,37 @@ static const struct pinctrl_function 
> msm_pinctrl_functions[] = {
> {"gpio", 0},
>  };
>
> +#define SDC_QDSD_PINGROUP(pg_name, ctl, pull, drv) \
> +   {   \
> +   .name = pg_name,\
> +   .ctl_reg = ctl, \
> +   .io_reg = 0,\
> +   .pull_bit = pull,   \
> +   .drv_bit = drv, \
> +   .oe_bit = -1,   \
> +   .in_bit = -1,   \
> +   .out_bit = -1,  \
> +   }
> +
> +#define UFS_RESET(pg_name, ctl, io)\
> +   {   \
> +   .name = pg_name,\
> +   .ctl_reg = ctl, \
> +   .io_reg = io,   \
> +   .pull_bit = 3,  \
> +   .drv_bit = 0,   \
> +   .oe_bit = -1,   \
> +   .in_bit = -1,   \
> +   .out_bit = 0,   \
> +   }
> +
> +static const struct msm_special_pin_data msm_special_pins_data[] = {
> +   [0] = UFS_RESET("ufs_reset", 0xde000, 0xde004),
> +   [1] = SDC_QDSD_PINGROUP("sdc2_clk", 0xd6000, 14, 6),
> +   [2] = SDC_QDSD_PINGROUP("sdc2_cmd", 0xd6000, 11, 3),
> +   [3] = SDC_QDSD_PINGROUP("sdc2_data", 0xd6000, 9, 0),
> +};
> +
>  static const char *sm8550_get_function_name(struct udevice *dev,
>  unsigned int selector)
>  {
> @@ -27,15 +58,9 @@ static const char *sm8550_get_function_name(struct udevice 
> *dev,
>  static const char *sm8550_get_pin_name(struct udevice *dev,
> unsigned int selector)
>  {
> -   static const char *special_pins_names[] = {
> -   "ufs_reset",
> -   "sdc2_clk",
> -   "sdc2_cmd",
> -   "sdc2_data",
> -   };
> -
> if (selector >= 210 && selector <= 213)
> -   snprintf(pin_name, MAX_PIN_NAME_LEN, 
> special_pins_names[selector - 210]);
> +   snprintf(pin_name, MAX_PIN_NAME_LEN,
> +msm_special_pins_data[selector - 210].name);
> else
> snprintf(pin_name, MAX_PIN_NAME_LEN, "gpio%u", selector);
>
> @@ -52,6 +77,7 @@ static struct msm_pinctrl_data sm8550_data = {
> .pin_data = {
> .pin_count = 214,
> .special_pins_start = 210,
> +   .special_pins_data = msm_special_pins_data,
> },
> .functions_count = ARRAY_SIZE(msm_pinctrl_functions),
> .get_function_name = sm8550_get_function_name,
>
> --
> 2.34.1
>


Re: [PATCH 3/5] pinctrl: qcom: add support setting pin configuration for special pins

2024-05-29 Thread Sumit Garg
On Tue, 28 May 2024 at 14:02, Neil Armstrong  wrote:
>
> Use the previously introduced msm_special_pin_data to setup the special
> pins configuration if the SoC driver have them specified.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/pinctrl/qcom/pinctrl-qcom.c | 37 
> +++--
>  1 file changed, 35 insertions(+), 2 deletions(-)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c 
> b/drivers/pinctrl/qcom/pinctrl-qcom.c
> index 4f4e9a83949..26a3fba194a 100644
> --- a/drivers/pinctrl/qcom/pinctrl-qcom.c
> +++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
> @@ -103,14 +103,47 @@ static int msm_pinmux_set(struct udevice *dev, unsigned 
> int pin_selector,
> return 0;
>  }
>
> +static int msm_pinconf_set_special(struct msm_pinctrl_priv *priv, unsigned 
> int pin_selector,
> +  unsigned int param, unsigned int argument)
> +{
> +   unsigned int offset = pin_selector - 
> priv->data->pin_data.special_pins_start;
> +   const struct msm_special_pin_data *data;
> +
> +   if (!priv->data->pin_data.special_pins_data)
> +   return 0;
> +
> +   data = >data->pin_data.special_pins_data[offset];
> +
> +   switch (param) {
> +   case PIN_CONFIG_DRIVE_STRENGTH:
> +   argument = (argument / 2) - 1;
> +   clrsetbits_le32(priv->base + data->ctl_reg,
> +   GENMASK(2, 0) << data->drv_bit,
> +   argument << data->drv_bit);
> +   break;
> +   case PIN_CONFIG_BIAS_DISABLE:
> +   clrbits_le32(priv->base + data->ctl_reg,
> +TLMM_GPIO_PULL_MASK << data->pull_bit);
> +   break;
> +   case PIN_CONFIG_BIAS_PULL_UP:
> +   clrsetbits_le32(priv->base + data->ctl_reg,
> +   TLMM_GPIO_PULL_MASK << data->pull_bit,
> +   argument << data->pull_bit);
> +   break;
> +   default:
> +   return 0;
> +   }
> +
> +   return 0;
> +}
> +
>  static int msm_pinconf_set(struct udevice *dev, unsigned int pin_selector,
>unsigned int param, unsigned int argument)
>  {
> struct msm_pinctrl_priv *priv = dev_get_priv(dev);
>
> -   /* Always NOP for special pins */
> if (qcom_is_special_pin(>data->pin_data, pin_selector))
> -   return 0;
> +   return msm_pinconf_set_special(priv, pin_selector, param, 
> argument);
>
> switch (param) {
> case PIN_CONFIG_DRIVE_STRENGTH:
>
> --
> 2.34.1
>


Re: [PATCH 2/5] arm: mach-snapdragon: gpio: introduce msm_special_pin_data

2024-05-29 Thread Sumit Garg
On Tue, 28 May 2024 at 14:02, Neil Armstrong  wrote:
>
> In order to help setup pin configuration for special pins (UFS, SDCard),
> introduce the msm_special_pin_data struct largely inspired from the
> Linux conterpart but with only U-Boot required fields.
>
> This struct is added to the pins_data to allow specifying the special
> pins data for each SoC.
>
> Signed-off-by: Neil Armstrong 
> ---
>  arch/arm/mach-snapdragon/include/mach/gpio.h | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/mach-snapdragon/include/mach/gpio.h 
> b/arch/arm/mach-snapdragon/include/mach/gpio.h
> index 53c6ae06490..cc8f405e20b 100644
> --- a/arch/arm/mach-snapdragon/include/mach/gpio.h
> +++ b/arch/arm/mach-snapdragon/include/mach/gpio.h
> @@ -10,11 +10,25 @@
>  #include 
>  #include 
>
> +struct msm_special_pin_data {
> +   char *name;
> +
> +   u32 ctl_reg;
> +   u32 io_reg;
> +
> +   unsigned pull_bit:5;
> +   unsigned drv_bit:5;
> +
> +   unsigned oe_bit:5;
> +   unsigned in_bit:5;
> +   unsigned out_bit:5;
> +};
> +
>  struct msm_pin_data {
> int pin_count;
> const unsigned int *pin_offsets;
> -   /* Index of first special pin, these are ignored for now */
> unsigned int special_pins_start;
> +   const struct msm_special_pin_data *special_pins_data;
>  };
>
>  static inline u32 qcom_pin_offset(const unsigned int *offs, unsigned int 
> selector)
>
> --
> 2.34.1
>


Re: [PATCH 1/5] pinctrl: qcom: add support for bias-pull-down

2024-05-28 Thread Sumit Garg
Hi Neil,

On Tue, 28 May 2024 at 14:02, Neil Armstrong  wrote:
>
> Add support for bias-pull-down as an alternate of bias-pull-up.

nit: s/alternate/alternative/

>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/pinctrl/qcom/pinctrl-qcom.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c 
> b/drivers/pinctrl/qcom/pinctrl-qcom.c
> index 3c3336e7635..4f4e9a83949 100644
> --- a/drivers/pinctrl/qcom/pinctrl-qcom.c
> +++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
> @@ -44,6 +44,7 @@ static const struct pinconf_param msm_conf_params[] = {
> { "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 2 },
> { "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
> { "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 3 },
> +   { "bias-pull-down", PIN_CONFIG_BIAS_PULL_UP, 1 },

Did you mean PIN_CONFIG_BIAS_PULL_DOWN here instead?

-Sumit

> { "output-high", PIN_CONFIG_OUTPUT, 1, },
> { "output-low", PIN_CONFIG_OUTPUT, 0, },
>  };
>
> --
> 2.34.1
>


Re: [PATCH 2/2] ARM: dts: renesas: Drop R8A779H0 V4M DTs with OF_UPSTREAM counterparts

2024-05-26 Thread Sumit Garg
On Sun, 26 May 2024 at 23:31, Marek Vasut
 wrote:
>
> Remove R8A779H0 V4M DTs which are now replaced by OF_UPSTREAM counterparts.
> No functional change expected.
>
> This patch finalizes OF_UPSTREAM conversion of R8A779H0 V4M which DTs landed
> in Linux 6.9 .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Adam Ford 
> Cc: Hai Pham 
> Cc: Paul Barker 
> Cc: Sumit Garg 
> Cc: Tom Rini 
> Cc: u-boot@lists.denx.de
> ---
>  arch/arm/dts/Makefile |   3 -
>  arch/arm/dts/r8a779h0-gray-hawk-cpu.dtsi  | 166 ---
>  arch/arm/dts/r8a779h0-gray-hawk-csi-dsi.dtsi  |  15 -
>  arch/arm/dts/r8a779h0-gray-hawk-ethernet.dtsi |  15 -
>  arch/arm/dts/r8a779h0-gray-hawk-u-boot.dtsi   |  41 --
>  arch/arm/dts/r8a779h0-gray-hawk.dts   |  25 -
>  arch/arm/dts/r8a779h0-u-boot.dtsi |  27 -
>  arch/arm/dts/r8a779h0.dtsi| 460 --
>  8 files changed, 752 deletions(-)
>  delete mode 100644 arch/arm/dts/r8a779h0-gray-hawk-cpu.dtsi
>  delete mode 100644 arch/arm/dts/r8a779h0-gray-hawk-csi-dsi.dtsi
>  delete mode 100644 arch/arm/dts/r8a779h0-gray-hawk-ethernet.dtsi
>  delete mode 100644 arch/arm/dts/r8a779h0-gray-hawk-u-boot.dtsi
>  delete mode 100644 arch/arm/dts/r8a779h0-gray-hawk.dts
>  delete mode 100644 arch/arm/dts/r8a779h0-u-boot.dtsi
>  delete mode 100644 arch/arm/dts/r8a779h0.dtsi
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f7032f1e175..6d5ff1bc27b 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -958,9 +958,6 @@ dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
> imxrt1020-evk.dtb \
> imxrt1170-evk.dtb \
>
> -dtb-$(CONFIG_RCAR_GEN4) += \
> -   r8a779h0-gray-hawk.dtb
> -
>  dtb-$(CONFIG_TARGET_RZG2L) += \
> r9a07g044l2-smarc.dts
>
> diff --git a/arch/arm/dts/r8a779h0-gray-hawk-cpu.dtsi 
> b/arch/arm/dts/r8a779h0-gray-hawk-cpu.dtsi
> deleted file mode 100644
> index c8a46219826..000
> --- a/arch/arm/dts/r8a779h0-gray-hawk-cpu.dtsi
> +++ /dev/null
> @@ -1,166 +0,0 @@
> -// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> -/*
> - * Device Tree Source for the Gray Hawk CPU board
> - *
> - * Copyright (C) 2023 Renesas Electronics Corp.
> - */
> -
> -#include 
> -#include 
> -
> -#include "r8a779h0.dtsi"
> -
> -/ {
> -   model = "Renesas Gray Hawk CPU board";
> -   compatible = "renesas,grayhawk-cpu", "renesas,r8a779h0";
> -
> -   aliases {
> -   ethernet0 = 
> -   serial0 = 
> -   };
> -
> -   chosen {
> -   bootargs = "ignore_loglevel";
> -   stdout-path = "serial0:921600n8";
> -   };
> -
> -   memory@4800 {
> -   device_type = "memory";
> -   /* first 128MB is reserved for secure area. */
> -   reg = <0x0 0x4800 0x0 0x7800>;
> -   };
> -
> -   memory@48000 {
> -   device_type = "memory";
> -   reg = <0x4 0x8000 0x1 0x8000>;
> -   };
> -
> -   reg_1p8v: regulator-1p8v {
> -   compatible = "regulator-fixed";
> -   regulator-name = "fixed-1.8V";
> -   regulator-min-microvolt = <180>;
> -   regulator-max-microvolt = <180>;
> -   regulator-boot-on;
> -   regulator-always-on;
> -   };
> -
> -   reg_3p3v: regulator-3p3v {
> -   compatible = "regulator-fixed";
> -   regulator-name = "fixed-3.3V";
> -   regulator-min-microvolt = <330>;
> -   regulator-max-microvolt = <330>;
> -   regulator-boot-on;
> -   regulator-always-on;
> -   };
> -};
> -
> - {
> -   pinctrl-0 = <_pins>;
> -   pinctrl-names = "default";
> -   phy-handle = <>;
> -   tx-internal-delay-ps = <2000>;
> -   status = "okay";
> -
> -   phy0: ethernet-phy@0 {
> -   compatible = "ethernet-phy-id0022.1622",
> -"ethernet-phy-ieee802.3-c22";
> -   rxc-skew-ps = <1500>;
> -   reg = <0>;
> -   interrupt-parent = <>;
> -   interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> -   reset-gpios = < 10 GPIO_ACTIVE_LOW>;
> -

Re: [PATCH 1/2] ARM: dts: renesas: Switch to using upstream DT on Renesas R8A779H0 V4M

2024-05-26 Thread Sumit Garg
On Sun, 26 May 2024 at 23:31, Marek Vasut
 wrote:
>
> Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the
> DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
> including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.
>
> This patch finalizes OF_UPSTREAM conversion of R8A779H0 V4M which DTs
> landed in Linux 6.9 .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Adam Ford 
> Cc: Hai Pham 
> Cc: Paul Barker 
> Cc: Sumit Garg 
> Cc: Tom Rini 
> Cc: u-boot@lists.denx.de
> ---
>  configs/r8a779h0_grayhawk_defconfig | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/configs/r8a779h0_grayhawk_defconfig 
> b/configs/r8a779h0_grayhawk_defconfig
> index 6bd872f063f..a986a09b8e0 100644
> --- a/configs/r8a779h0_grayhawk_defconfig
> +++ b/configs/r8a779h0_grayhawk_defconfig
> @@ -5,7 +5,7 @@ CONFIG_SYS_MALLOC_LEN=0x400
>  CONFIG_ENV_SIZE=0x2
>  CONFIG_ENV_OFFSET=0xFFFE
>  CONFIG_DM_GPIO=y
> -CONFIG_DEFAULT_DEVICE_TREE="r8a779h0-gray-hawk"
> +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a779h0-gray-hawk-single"
>  CONFIG_RCAR_GEN4=y
>  CONFIG_TARGET_GRAYHAWK=y
>  CONFIG_SYS_MONITOR_LEN=1048576
> @@ -39,7 +39,6 @@ CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_OF_CONTROL=y
> -# CONFIG_OF_UPSTREAM is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SYS_MMC_ENV_PART=2
> --
> 2.43.0
>


Re: [PATCH] arm: exynos: Migrate E850-96 board to OF_UPSTREAM

2024-05-23 Thread Sumit Garg
+ Krzysztof, Fyi..

On Fri, 24 May 2024 at 03:33, Sam Protsenko  wrote:
>
> Use upstream device tree files and bindings. To do so:
>  - imply (enable) OF_UPSTREAM option for E850-96 target
>  - point DEFAULT_DEVICE_TREE in E850-96 config to upstream dts
>  - remove now not needed local dts files, binding docs and headers
>  - update MAINTAINERS correspondingly
>
> Upstream device tree files for Exynos850 SoC and E850-96 board are
> pretty much the same as local (removed) ones, so the conversion is
> rather straightforward and painless in this case. The appended dts file
> (arch/arm/dts/exynos850-e850-96-u-boot.dtsi) stays unchanged.
>
> The only remaining local dt-bindings doc for E850-96 board is
> exynos-pmu.yaml. It wasn't removed as it's quite different from Linux
> kernel version. Particularly U-Boot local version of exynos-pmu.yaml
> describes "samsung,uart-debug-1" property, which is not present in Linux
> kernel binding. Later it might be upstreamed to Linux kernel, and once
> it's done the U-Boot exynos-pmu.yaml binding can be removed.
>
> No functional change.
>
> Signed-off-by: Sam Protsenko 
> ---
>  MAINTAINERS   |   7 +-
>  arch/arm/dts/Makefile |   1 -
>  arch/arm/dts/exynos850-e850-96.dts| 273 --
>  arch/arm/dts/exynos850-pinctrl.dtsi   | 663 --
>  arch/arm/dts/exynos850.dtsi   | 809 --
>  arch/arm/mach-exynos/Kconfig  |   1 +
>  configs/e850-96_defconfig |   2 +-
>  .../clock/samsung,exynos850-clock.yaml| 307 ---
>  .../soc/samsung/exynos-usi.yaml   | 162 
>  include/dt-bindings/clock/exynos850.h | 337 
>  include/dt-bindings/soc/samsung,exynos-usi.h  |  17 -
>  11 files changed, 3 insertions(+), 2576 deletions(-)
>  delete mode 100644 arch/arm/dts/exynos850-e850-96.dts
>  delete mode 100644 arch/arm/dts/exynos850-pinctrl.dtsi
>  delete mode 100644 arch/arm/dts/exynos850.dtsi
>  delete mode 100644 
> doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml
>  delete mode 100644 doc/device-tree-bindings/soc/samsung/exynos-usi.yaml
>  delete mode 100644 include/dt-bindings/clock/exynos850.h
>  delete mode 100644 include/dt-bindings/soc/samsung,exynos-usi.h
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 638b2fdd442f..f8afd7d51e2e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -578,19 +578,14 @@ F:drivers/clk/exynos/clk.h
>  ARM SAMSUNG EXYNOS850 SOC
>  M: Sam Protsenko 
>  S: Maintained
> -F: arch/arm/dts/exynos850-pinctrl.dtsi
> -F: arch/arm/dts/exynos850.dtsi
> -F: doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml
>  F: drivers/clk/exynos/clk-exynos850.c
>  F: drivers/pinctrl/exynos/pinctrl-exynos850.c
> -F: include/dt-bindings/clock/exynos850.h
>
>  ARM SAMSUNG SOC DRIVERS
>  M: Sam Protsenko 
>  S: Maintained
> -F: doc/device-tree-bindings/soc/samsung/*
> +F: doc/device-tree-bindings/soc/samsung/exynos-pmu.yaml
>  F: drivers/soc/samsung/*
> -F: include/dt-bindings/soc/samsung,*.h
>
>  ARM SANCLOUD
>  M: Paul Barker 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a5c82ebf7a5f..4b72d9f64863 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -31,7 +31,6 @@ dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
>  dtb-$(CONFIG_TARGET_A5Y17LTE) += exynos78x0-axy17lte.dtb
>  dtb-$(CONFIG_TARGET_A3Y17LTE) += exynos78x0-axy17lte.dtb
>  dtb-$(CONFIG_TARGET_A7Y17LTE) += exynos78x0-axy17lte.dtb
> -dtb-$(CONFIG_TARGET_E850_96) += exynos850-e850-96.dtb
>
>  dtb-$(CONFIG_ARCH_APPLE) += \
> t8103-j274.dtb \
> diff --git a/arch/arm/dts/exynos850-e850-96.dts 
> b/arch/arm/dts/exynos850-e850-96.dts
> deleted file mode 100644
> index f074df8982b3..
> --- a/arch/arm/dts/exynos850-e850-96.dts
> +++ /dev/null
> @@ -1,273 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * WinLink E850-96 board device tree source
> - *
> - * Copyright (C) 2018 Samsung Electronics Co., Ltd.
> - * Copyright (C) 2021 Linaro Ltd.
> - *
> - * Device tree source file for WinLink's E850-96 board which is based on
> - * Samsung Exynos850 SoC.
> - */
> -
> -/dts-v1/;
> -
> -#include "exynos850.dtsi"
> -#include 
> -#include 
> -#include 
> -
> -/ {
> -   model = "WinLink E850-96 board";
> -   compatible = "winlink,e850-96", "samsung,exynos850";
> -
> -   aliases {
> -   mmc0 = _0;
> -   serial0 = _0;
> -  

Re: [PATCH v2 2/5] dt-bindings: clock: qcom: ipq4019: drop downstream file

2024-05-23 Thread Sumit Garg
On Thu, 23 May 2024 at 23:08, Robert Marko  wrote:
>
> IPQ4019 clock dt-bindings are available in Linux upstream, and we can just
> use those instead of carrying a downstream file that matches the upstream one
> anyway.
>
> Signed-off-by: Robert Marko 
> ---
> Changes in v2:
> * Drop the downstream dt-bindings header as it matches the upstream Linux one
>
>  include/dt-bindings/clock/qcom,gcc-ipq4019.h | 169 ---
>  1 file changed, 169 deletions(-)
>  delete mode 100644 include/dt-bindings/clock/qcom,gcc-ipq4019.h
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/include/dt-bindings/clock/qcom,gcc-ipq4019.h 
> b/include/dt-bindings/clock/qcom,gcc-ipq4019.h
> deleted file mode 100644
> index 7e8a7be6dc..00
> --- a/include/dt-bindings/clock/qcom,gcc-ipq4019.h
> +++ /dev/null
> @@ -1,169 +0,0 @@
> -/* Copyright (c) 2015 The Linux Foundation. All rights reserved.
> - *
> - * Permission to use, copy, modify, and/or distribute this software for any
> - * purpose with or without fee is hereby granted, provided that the above
> - * copyright notice and this permission notice appear in all copies.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> - *
> - */
> -#ifndef __QCOM_CLK_IPQ4019_H__
> -#define __QCOM_CLK_IPQ4019_H__
> -
> -#define GCC_DUMMY_CLK  0
> -#define AUDIO_CLK_SRC  1
> -#define BLSP1_QUP1_I2C_APPS_CLK_SRC2
> -#define BLSP1_QUP1_SPI_APPS_CLK_SRC3
> -#define BLSP1_QUP2_I2C_APPS_CLK_SRC4
> -#define BLSP1_QUP2_SPI_APPS_CLK_SRC5
> -#define BLSP1_UART1_APPS_CLK_SRC   6
> -#define BLSP1_UART2_APPS_CLK_SRC   7
> -#define GCC_USB3_MOCK_UTMI_CLK_SRC 8
> -#define GCC_APPS_CLK_SRC   9
> -#define GCC_APPS_AHB_CLK_SRC   10
> -#define GP1_CLK_SRC11
> -#define GP2_CLK_SRC12
> -#define GP3_CLK_SRC13
> -#define SDCC1_APPS_CLK_SRC 14
> -#define FEPHY_125M_DLY_CLK_SRC 15
> -#define WCSS2G_CLK_SRC 16
> -#define WCSS5G_CLK_SRC 17
> -#define GCC_APSS_AHB_CLK   18
> -#define GCC_AUDIO_AHB_CLK  19
> -#define GCC_AUDIO_PWM_CLK  20
> -#define GCC_BLSP1_AHB_CLK  21
> -#define GCC_BLSP1_QUP1_I2C_APPS_CLK22
> -#define GCC_BLSP1_QUP1_SPI_APPS_CLK23
> -#define GCC_BLSP1_QUP2_I2C_APPS_CLK24
> -#define GCC_BLSP1_QUP2_SPI_APPS_CLK25
> -#define GCC_BLSP1_UART1_APPS_CLK   26
> -#define GCC_BLSP1_UART2_APPS_CLK   27
> -#define GCC_DCD_XO_CLK 28
> -#define GCC_GP1_CLK29
> -#define GCC_GP2_CLK30
> -#define GCC_GP3_CLK31
> -#define GCC_BOOT_ROM_AHB_CLK   32
> -#define GCC_CRYPTO_AHB_CLK 33
> -#define GCC_CRYPTO_AXI_CLK 34
> -#define GCC_CRYPTO_CLK 35
> -#define GCC_ESS_CLK36
> -#define GCC_IMEM_AXI_CLK   37
> -#define GCC_IMEM_CFG_AHB_CLK   38
> -#define GCC_PCIE_AHB_CLK   39
> -#define GCC_PCIE_AXI_M_CLK 40
> -#define GCC_PCIE_AXI_S_CLK 41
> -#define GCC_PCNOC_AHB_CLK  42
> -#define GCC_PRNG_AHB_CLK   43
> -#define GCC_QPIC_AHB_CLK   44
> -#define GCC_QPIC_CLK   45
> -#define GCC_SDCC1_AHB_CLK  46
> -#define GCC_SDCC1_APPS_CLK 47
> -#define GCC_SNOC_PCNOC_AHB_CLK

Re: [PATCH v2] arm: dts: k3-j7200: Move to OF_UPSTREAM

2024-05-23 Thread Sumit Garg
On Tue, 21 May 2024 at 11:18, Aniket Limaye  wrote:
>
> Move to using OF_UPSTREAM config and thus using the devicetree-rebasing
> subtree.
>
> Signed-off-by: Aniket Limaye 
> ---
>
> Boot logs:
> https://gist.github.com/aniket-l/aab91bb12d2495c54da094fca49c369f
>
> Changes in v2:
> - Rebased to next
> - Removed dependency on binman templating series [1] as per [2]
>
> [1]: https://lore.kernel.org/all/20240322131011.1029620-1-n-fran...@ti.com/
> [2]: https://lore.kernel.org/u-boot/20240520095916.1809962-1-n-fran...@ti.com/
>
> ---
>  arch/arm/dts/Makefile |1 -
>  arch/arm/dts/k3-j7200-binman.dtsi |2 +-
>  .../k3-j7200-common-proc-board-u-boot.dtsi|   14 +-
>  arch/arm/dts/k3-j7200-common-proc-board.dts   |  396 -
>  arch/arm/dts/k3-j7200-main.dtsi   | 1284 -
>  arch/arm/dts/k3-j7200-mcu-wakeup.dtsi |  647 -
>  arch/arm/dts/k3-j7200-som-p0.dtsi |  327 -
>  arch/arm/dts/k3-j7200-thermal.dtsi|   47 -
>  arch/arm/dts/k3-j7200.dtsi|  164 ---
>  configs/j7200_evm_a72_defconfig   |3 +-
>  10 files changed, 8 insertions(+), 2877 deletions(-)
>  delete mode 100644 arch/arm/dts/k3-j7200-common-proc-board.dts
>  delete mode 100644 arch/arm/dts/k3-j7200-main.dtsi
>  delete mode 100644 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
>  delete mode 100644 arch/arm/dts/k3-j7200-som-p0.dtsi
>  delete mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
>  delete mode 100644 arch/arm/dts/k3-j7200.dtsi
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f7032f1e175..ea8fee8e25c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1194,7 +1194,6 @@ dtb-$(CONFIG_SOC_K3_AM654) += \
>
>  dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
>   k3-j721e-r5-common-proc-board.dtb \
> - k3-j7200-common-proc-board.dtb \
>   k3-j7200-r5-common-proc-board.dtb \
>   k3-j721e-sk.dtb \
>   k3-j721e-r5-sk.dtb \
> diff --git a/arch/arm/dts/k3-j7200-binman.dtsi 
> b/arch/arm/dts/k3-j7200-binman.dtsi
> index 06db8659876..b6e0aa37971 100644
> --- a/arch/arm/dts/k3-j7200-binman.dtsi
> +++ b/arch/arm/dts/k3-j7200-binman.dtsi
> @@ -180,7 +180,7 @@
>
>  #ifdef CONFIG_TARGET_J7200_A72_EVM
>
> -#define SPL_J7200_EVM_DTB "spl/dts/k3-j7200-common-proc-board.dtb"
> +#define SPL_J7200_EVM_DTB "spl/dts/ti/k3-j7200-common-proc-board.dtb"
>  #define J7200_EVM_DTB "u-boot.dtb"
>
>   {
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi 
> b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> index 485f17c5f06..045ef170e17 100644
> --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> @@ -26,8 +26,12 @@
>  _mcu_wakeup {
> bootph-all;
>
> -   chipid@4314 {
> +   wkup_conf: bus@4300 {
> bootph-all;
> +
> +   chipid: chipid@14 {
> +   bootph-all;
> +   };
> };
>  };
>
> @@ -40,14 +44,6 @@
>  };
>
>  _udmap {
> -   reg = <0x0 0x285c 0x0 0x100>,
> -   <0x0 0x284c 0x0 0x4000>,
> -   <0x0 0x2a80 0x0 0x4>,
> -   <0x0 0x284a 0x0 0x4000>,
> -   <0x0 0x2aa0 0x0 0x4>,
> -   <0x0 0x2840 0x0 0x2000>;
> -   reg-names = "gcfg", "rchan", "rchanrt", "tchan",
> -   "tchanrt", "rflow";
> bootph-all;
>  };
>
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts 
> b/arch/arm/dts/k3-j7200-common-proc-board.dts
> deleted file mode 100644
> index cee2b4b0eb8..000
> --- a/arch/arm/dts/k3-j7200-common-proc-board.dts
> +++ /dev/null
> @@ -1,396 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
> - */
> -
> -/dts-v1/;
> -
> -#include "k3-j7200-som-p0.dtsi"
> -#include 
> -#include 
> -#include 
> -
> -#include "k3-serdes.h"
> -
> -/ {
> -   compatible = "ti,j7200-evm", "ti,j7200";
> -   model = "Texas Instruments J7200 EVM";
> -
> -   aliases {
> -   serial0 = _uart0;
> -   serial1 = _uart0;
> -   serial2 = _uart0;
> -

Re: [PATCH v2] board: rockchip: add ArmSoM Sige7 Rk3588 board

2024-05-23 Thread Sumit Garg
On Wed, 22 May 2024 at 23:33, Quentin Schulz  wrote:
>
> Hi Jianfeng Liu,
>
> On 5/22/24 6:58 PM, Jianfeng Liu wrote:
> [...]
> > Note that these commits:
> > - e18e5e8188f2 (arm64: dts: rockchip: add USBDP phys on rk3588)
> > - 6fca4edb93d3 (arm64: dts: rockchip: Add rk3588 GPU node)
> > are not synced to u-boot, so I remove usb3 drd nodes and gpu from kernel
> > devicetree.
> [...]> diff --git
> a/dts/upstream/src/arm64/rockchip/rk3588-armsom-sige7.dts
> b/dts/upstream/src/arm64/rockchip/rk3588-armsom-sige7.dts
> > new file mode 100644
> > index 00..c7b46536ec
> > --- /dev/null
> > +++ b/dts/upstream/src/arm64/rockchip/rk3588-armsom-sige7.dts
>
> Sorry, I failed to explain properly what was expected.
>
> dts/upstream should never be touched except with
> dts/update-dts-subtree.sh script.
>
> Sadly, your board is not supported in v6.9 yet, only in the upcoming
> v6.10 :/
>
> So we have two options, we keep the dts in arch/arm/dts/ like you used
> to do, until we merge v6.10 dts in U-Boot (probably for v2024.10?), or
> we cherry-pick the changes for your board with dts/update-dts-subtree.sh
> script, see the instructions in the docs Tom has started writing:
> https://lore.kernel.org/u-boot/20240517174930.1028063-2-tr...@konsulko.com/.
> I would very much like to see someone starting to look into the second
> option :)
>
> However... it seems we'll likely need to also cherry-pick patches for
> the GPU (should probably be straightforward as nothing would be using
> the GPU anyway in U-Boot) and the USBDP PHY... but this one we would
> need to update all -u-boot.dtsi for rk3588(s) boards that have it
> already to make it use the new label/DT, make sure that the driver still
> works... etc. Maybe not a small feat, but someone will have to do it at
> some point anyway :)
>
> You'd be the first one to do this cherry-picking into dts/upstream, so
> it'd be really interesting to us if you could provide feedback on what
> is unclear/not working, etc... so we can update the documentation or fix
> tools if they were to be insufficient.

+1

Although it is very much similar to normal cherry-picking patches, the
dts/update-dts-subtree.sh script is just there to hide the git subtree
specific details.

-Sumit

>
> Looking forward to your next patch,
> Cheers,
> Quentin


Re: [PATCH] arm: dts: mvebu: Migrate to upstream DT for Synology DS116 (Armada 385) board

2024-05-23 Thread Sumit Garg
On Thu, 23 May 2024 at 03:22, Tony Dinh  wrote:
>
> Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the
> DEFAULT_DEVICE_TREE in DS116 defconfig. Remove current DTS in
> arch/arm/dts/ directory.
>
> Signed-off-by: Tony Dinh 
> ---
>
>  arch/arm/dts/Makefile  |   1 -
>  arch/arm/dts/armada-385-synology-ds116.dts | 291 -
>  configs/ds116_defconfig|   3 +-
>  3 files changed, 2 insertions(+), 293 deletions(-)
>  delete mode 100644 arch/arm/dts/armada-385-synology-ds116.dts
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a5c82ebf7a..75f7e616b4 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -155,7 +155,6 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
> armada-385-atl-x530.dtb \
> armada-385-atl-x530DP.dtb   \
> armada-385-db-88f6820-amc.dtb   \
> -   armada-385-synology-ds116.dtb   \
> armada-385-thecus-n2350.dtb \
> armada-385-turris-omnia.dtb \
> armada-388-clearfog.dtb \
> diff --git a/arch/arm/dts/armada-385-synology-ds116.dts 
> b/arch/arm/dts/armada-385-synology-ds116.dts
> deleted file mode 100644
> index 82a0373f7f..00
> --- a/arch/arm/dts/armada-385-synology-ds116.dts
> +++ /dev/null
> @@ -1,291 +0,0 @@
> -// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> -/*
> - * Device Tree file for Synology DS116 NAS
> - *
> - * Copyright (C) 2017 Willy Tarreau 
> - */
> -
> -/dts-v1/;
> -#include "armada-385.dtsi"
> -#include 
> -
> -/ {
> -   model = "Synology DS116";
> -   compatible = "marvell,a385-gp", "marvell,armada385", 
> "marvell,armada380";
> -
> -   chosen {
> -   stdout-path = "serial0:115200n8";
> -   };
> -
> -   memory {
> -   device_type = "memory";
> -   reg = <0x 0x4000>; /* 1 GB */
> -   };
> -
> -   soc {
> -   ranges =  - MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> - MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> - MBUS_ID(0x09, 0x15) 0 0xf111 0x1
> - MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
> -
> -   internal-regs {
> -   i2c@11000 {
> -   pinctrl-names = "default";
> -   pinctrl-0 = <_pins>;
> -   status = "okay";
> -   clock-frequency = <10>;
> -
> -   eeprom@57 {
> -   compatible = "atmel,24c64";
> -   reg = <0x57>;
> -   };
> -   };
> -
> -   serial@12000 {
> -   pinctrl-names = "default";
> -   pinctrl-0 = <_pins>;
> -   status = "okay";
> -   };
> -
> -   serial@12100 {
> -   /* A PIC16F1829 is connected to uart1 at 9600 
> bps,
> -* and takes single-character orders :
> -*   "1" : power off // already handled by 
> the poweroff node
> -*   "2" : short beep
> -*   "3" : long beep
> -*   "4" : turn the power LED ON
> -*   "5" : flash the power LED
> -*   "6" : turn the power LED OFF
> -*   "7" : turn the status LED OFF
> -*   "8" : turn the status LED ON
> -*   "9" : flash the status LED
> -*   "A" : flash the motherboard LED (D8)
> -*   "B" : turn the motherboard LED OFF
> -*   "C" : hard reset
> -*/
> -   pinctrl-names = "default";
> -   pinctrl-0 = <_pins>;
> -   status = "okay";
> -   };

Re: [PATCH FOR TESTING ONLY RFC 4/4] sunxi-d1s-t113: Add D1 and T113 PWM node

2024-05-20 Thread Sumit Garg
On Sat, 18 May 2024 at 09:25, John Watts  wrote:
>
> This is based on the binding from the as yet unmerged kernel series:
>
> https://lore.kernel.org/linux-kernel/20240131125920.2879433-2-privates...@gmail.com/
>
> Signed-off-by: John Watts 
> ---
>  arch/riscv/dts/sunxi-d1s-t113.dtsi   | 12 
>  dts/upstream/src/riscv/allwinner/sunxi-d1s-t113.dtsi | 12 
>  2 files changed, 24 insertions(+)
>
> diff --git a/arch/riscv/dts/sunxi-d1s-t113.dtsi 
> b/arch/riscv/dts/sunxi-d1s-t113.dtsi
> index 822f022eec..92b6432f77 100644
> --- a/arch/riscv/dts/sunxi-d1s-t113.dtsi
> +++ b/arch/riscv/dts/sunxi-d1s-t113.dtsi
> @@ -145,6 +145,18 @@
> };
> };
>
> +   pwm: pwm@2000c00 {
> +   compatible = "allwinner,sun20i-d1-pwm";
> +   reg = <0x02000c00 0x400>;
> +   clocks = < CLK_BUS_PWM>,
> +<>,
> +< CLK_APB0>;
> +   clock-names = "bus", "hosc", "apb0";
> +   resets = < RST_BUS_PWM>;
> +   status = "disabled";
> +   #pwm-cells = <0x3>;
> +   };
> +
> ccu: clock-controller@2001000 {
> compatible = "allwinner,sun20i-d1-ccu";
> reg = <0x2001000 0x1000>;
> diff --git a/dts/upstream/src/riscv/allwinner/sunxi-d1s-t113.dtsi 
> b/dts/upstream/src/riscv/allwinner/sunxi-d1s-t113.dtsi
> index 5a9d7f5a75..435a1e66aa 100644
> --- a/dts/upstream/src/riscv/allwinner/sunxi-d1s-t113.dtsi
> +++ b/dts/upstream/src/riscv/allwinner/sunxi-d1s-t113.dtsi
> @@ -145,6 +145,18 @@
> };
> };
>
> +   pwm: pwm@2000c00 {
> +   compatible = "allwinner,sun20i-d1-pwm";
> +   reg = <0x02000c00 0x400>;
> +   clocks = < CLK_BUS_PWM>,
> +<>,
> +< CLK_APB0>;
> +   clock-names = "bus", "hosc", "apb0";
> +   resets = < RST_BUS_PWM>;
> +   status = "disabled";
> +   #pwm-cells = <0x3>;
> +   };
> +

This change shouldn't be needed for your testing purposes too. It only
comes into picture once you enable OF_UPSTREAM. BTW, DT source files
in dts/upstream are strictly following/syncing against Linux kernel DT
sources. So all the custom U-Boot specific DT stuff belongs to
arch/${ARCH}/dts/.

-Sumit

> ccu: clock-controller@2001000 {
> compatible = "allwinner,sun20i-d1-ccu";
> reg = <0x2001000 0x1000>;
>
> --
> 2.45.1
>


Re: [RESEND PATCH 4/4] omap3: igep0x00: Migrate to use upstream DT

2024-05-20 Thread Sumit Garg
On Sat, 18 May 2024 at 18:36, Javier Martinez Canillas
 wrote:
>
> From: Javier Martinez Canillas 
>
> Enable OF_UPSTREAM to use upstream DT and add a ti/omap/ prefix to the
> DEFAULT_DEVICE_TREE config option.
>
> That way, a DTS from the upstream dts/upstream/src/ directory is used
> instead of the arch/$(ARCH)/dts/ directory. These in turn are removed.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>
>  arch/arm/dts/Makefile   |   3 -
>  arch/arm/dts/omap3-igep.dtsi| 247 --
>  arch/arm/dts/omap3-igep0020-common.dtsi | 261 
>  arch/arm/dts/omap3-igep0020.dts |  47 -
>  configs/igep00x0_defconfig  |   3 +-
>  5 files changed, 2 insertions(+), 559 deletions(-)
>  delete mode 100644 arch/arm/dts/omap3-igep.dtsi
>  delete mode 100644 arch/arm/dts/omap3-igep0020-common.dtsi
>  delete mode 100644 arch/arm/dts/omap3-igep0020.dts
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a5c82ebf7a5f..a9bd4921718e 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1030,9 +1030,6 @@ dtb-$(CONFIG_TARGET_OMAP3_BEAGLE) += \
>
>  dtb-$(CONFIG_TARGET_DEVKIT8000) += omap3-devkit8000.dtb
>
> -dtb-$(CONFIG_TARGET_OMAP3_IGEP00X0) += \
> -   omap3-igep0020.dtb
> -
>  dtb-$(CONFIG_TARGET_OMAP4_PANDA) += \
> omap4-panda.dtb \
> omap4-panda-es.dtb
> diff --git a/arch/arm/dts/omap3-igep.dtsi b/arch/arm/dts/omap3-igep.dtsi
> deleted file mode 100644
> index 219202610463..
> --- a/arch/arm/dts/omap3-igep.dtsi
> +++ /dev/null
> @@ -1,247 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-only
> -/*
> - * Common device tree for IGEP boards based on AM/DM37x
> - *
> - * Copyright (C) 2012 Javier Martinez Canillas 
> - * Copyright (C) 2012 Enric Balletbo i Serra 
> - */
> -/dts-v1/;
> -
> -#include "omap36xx.dtsi"
> -
> -/ {
> -   memory@8000 {
> -   device_type = "memory";
> -   reg = <0x8000 0x2000>; /* 512 MB */
> -   };
> -
> -   chosen {
> -   stdout-path = 
> -   };
> -
> -   sound {
> -   compatible = "ti,omap-twl4030";
> -   ti,model = "igep2";
> -   ti,mcbsp = <>;
> -   };
> -
> -   vdd33: regulator-vdd33 {
> -   compatible = "regulator-fixed";
> -   regulator-name = "vdd33";
> -   regulator-always-on;
> -   };
> -
> -};
> -
> -_pmx_core {
> -   gpmc_pins: pinmux_gpmc_pins {
> -   pinctrl-single,pins = <
> -   /* OneNAND seems to require PIN_INPUT on clock. */
> -OMAP3_CORE1_IOPAD(0x20be, PIN_INPUT | MUX_MODE0) 
>/* gpmc_clk.gpmc_clk */
> -   >;
> -   };
> -
> -   uart1_pins: pinmux_uart1_pins {
> -   pinctrl-single,pins = <
> -   OMAP3_CORE1_IOPAD(0x2182, PIN_INPUT | MUX_MODE0)  
>   /* uart1_rx.uart1_rx */
> -   OMAP3_CORE1_IOPAD(0x217c, PIN_OUTPUT | MUX_MODE0) 
>   /* uart1_tx.uart1_tx */
> -   >;
> -   };
> -
> -   uart3_pins: pinmux_uart3_pins {
> -   pinctrl-single,pins = <
> -   OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)  
>   /* uart3_rx.uart3_rx */
> -   OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0) 
>   /* uart3_tx.uart3_tx */
> -   >;
> -   };
> -
> -   mcbsp2_pins: pinmux_mcbsp2_pins {
> -   pinctrl-single,pins = <
> -   OMAP3_CORE1_IOPAD(0x213c, PIN_INPUT | MUX_MODE0)  
>   /* mcbsp2_fsx.mcbsp2_fsx */
> -   OMAP3_CORE1_IOPAD(0x213e, PIN_INPUT | MUX_MODE0)  
>   /* mcbsp2_clkx.mcbsp2_clkx */
> -   OMAP3_CORE1_IOPAD(0x2140, PIN_INPUT | MUX_MODE0)  
>   /* mcbsp2_dr.mcbsp2.dr */
> -   OMAP3_CORE1_IOPAD(0x2142, PIN_OUTPUT | MUX_MODE0) 
>   /* mcbsp2_dx.mcbsp2_dx */
> -   >;
> -   };
> -
> -   mmc1_pins: pinmux_mmc1_pins {
> -   pinctrl-single,pins = <
> -   OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | 
> MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
> -   OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | 
> MUX_MODE0) /* sdmmc1_cmd.sdmmc1_cmd */
> -   OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | 
> MUX_MODE0) /* sdmmc1_dat0.sdmmc1_dat0 */
> -   OMAP3

Re: [PATCH 08/10] dts/upsteam: Add Makefile for xtensa

2024-05-20 Thread Sumit Garg
On Mon, 20 May 2024 at 02:24, Jiaxun Yang  wrote:
>
> It is required to get it xtensa OF_UPSTREAM work.
>
> Signed-off-by: Jiaxun Yang 
> ---
>  dts/upstream/src/xtensa/Makefile | 14 ++
>  1 file changed, 14 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/dts/upstream/src/xtensa/Makefile 
> b/dts/upstream/src/xtensa/Makefile
> new file mode 100644
> index ..2a81acb32bc3
> --- /dev/null
> +++ b/dts/upstream/src/xtensa/Makefile
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +include $(srctree)/scripts/Makefile.dts
> +
> +targets += $(dtb-y)
> +
> +# Add any required device tree compiler flags here
> +DTC_FLAGS += -a 0x8
> +
> +PHONY += dtbs
> +dtbs: $(addprefix $(obj)/, $(dtb-y))
> +   @:
> +
> +clean-files := *.dtb *.dtbo */*.dtb */*.dtbo
>
> --
> 2.43.0
>


Re: [PATCH] ARM: dts: renesas: Reserve space in 64bit R-Car DTs

2024-05-20 Thread Sumit Garg
On Mon, 20 May 2024 at 02:11, Marek Vasut
 wrote:
>
> Reserve 4 kiB of space in 64bit R-Car DTs when those DTs are compiled
> to permit patching in OpTee-OS /firmware node, /reserved-memory node,
> possibly also additional /memory@ nodes and RPC node by TFA.
>
> This duplicates behavior in arch/arm/dts/Makefile with OF_UPSTREAM.
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Sumit Garg 
> Cc: Tom Rini 
> ---
>  dts/upstream/src/arm64/Makefile | 4 
>  1 file changed, 4 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/dts/upstream/src/arm64/Makefile b/dts/upstream/src/arm64/Makefile
> index 9a8f6aa3584..26a83d3d29d 100644
> --- a/dts/upstream/src/arm64/Makefile
> +++ b/dts/upstream/src/arm64/Makefile
> @@ -7,6 +7,10 @@ targets += $(dtb-y)
>  # Add any required device tree compiler flags here
>  DTC_FLAGS += -a 0x8
>
> +ifdef CONFIG_RCAR_64
> +DTC_FLAGS += -R 4 -p 0x1000
> +endif
> +
>  PHONY += dtbs
>  dtbs: $(addprefix $(obj)/, $(dtb-y))
> @:
> --
> 2.43.0
>


Re: [PATCH v3 11/12] MIPS: boston: Migrate to OF_UPSTREAM

2024-05-20 Thread Sumit Garg
On Mon, 20 May 2024 at 04:17, Tom Rini  wrote:
>
> On Sun, May 19, 2024 at 09:57:03PM +0100, Jiaxun Yang wrote:
> >
> >
> > 在2024年5月19日五月 下午7:20,Daniel Schwierzeck写道:
> > >
> > > Reviewed-by: Daniel Schwierzeck 
> > >
> > Hi Daniel,
> >
> > Thanks for reviewing the series.
> > >
> > [...]
> > >
> > > should be 'select' because the switch to upstream DTS is permanent and
> > > it does not make sense for the user to be able to deselect this option
> > >
> >
> > Do you want me to send another version or are you going to fix
> > it as you apply the patch?
>
> So, in the case of OF_UPTREAM, it's "imply OF_UPSTREAM" everywhere else
> and while there's a case to be made it should be select instead, that's
> probably a future clean-up for all users.

I think it depends on whether OF_UPSTREAM is enabled for a SoC (with
multiple board variants) or a single target board (I suppose that's
the case here). For the former case, "imply" would be preferred since
we can't enforce a policy at SoC level where new boards are coming up
which have to opt out of OF_UPSTREAM. For the latter case, "select"
would be preferred. However, I agree that it can be a future cleanup
patch.

-Sumit

>
> --
> Tom


Re: [PATCH 12/13] MIPS: boston: Migrate to OF_UPSTREAM

2024-05-16 Thread Sumit Garg
On Thu, 16 May 2024 at 17:29, Jiaxun Yang  wrote:
>
>
>
> 在2024年5月14日五月 上午6:45,Sumit Garg写道:
> > Hi Jiaxun,
> >
> [...]
> >> @@ -0,0 +1,10 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +
> >> +_regs {
> >> +   compatible = "img,boston-platform-regs", "syscon", "simple-mfd";
> >> +   bootph-all;
> >> +};
> >> +
> >> +_boston {
> >> +   bootph-all;
> >> +};
> >
> > You can try to push these overrides to upstream DTS as well, so you
> > won't have to maintain them in U-Boot.
>
> Hi Sumit,
>
> Thanks for your comments! For the compatible override, I already sent
> patch to upstream. However, I have a question, Can we really do bootph-all
> in linux upstream?

Yes.

>
> I don't think it's documented in upstream dt bindings.
>

It has been documented as part of core schema DT bindings here [1].

[1] 
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml

-Sumit


Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-16 Thread Sumit Garg
On Wed, 15 May 2024 at 21:30, Tom Rini  wrote:
>
> On Wed, May 15, 2024 at 11:39:08AM +0200, Jonas Karlman wrote:
>
> [snip]
> > My main concern is how to best handle new boards and features/drivers.
> > E.g. for Rockchip the RK3588 SoC is under active development, new boards
> > and features/drivers are actively added/fixed in upstream Linux.
>
> To this question specifically, dts/update-dts-subtree.sh has a "pick"
> option and in some previous quick testing, it does what one would hope.
> So for this case you could pick the N commits that need to be brought
> it, the resulting patch would be small enough to send to the list
> normally (the resync patch for v6.9 is 2.7MB) and then when I do the
> next full resync it goes cleanly still.

That sounds like a good alternative although it was proposed for any
fixes to be incorporated but it's worth giving it a try for new
features too. I think as long as the cherry pick is clean with all
dependencies being picked up properly, the next sync should work
cleanly.

-Sumit

>
> --
> Tom


Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-15 Thread Sumit Garg
On Wed, 15 May 2024 at 15:09, Jonas Karlman  wrote:
>
> Hi Sumit,
>
> On 2024-05-15 10:49, Sumit Garg wrote:
> > Hi Jonas,
> >
> > On Wed, 15 May 2024 at 13:11, Jonas Karlman  wrote:
> >>
> >> Hi Tom,
> >>
> >> On 2024-05-14 18:42, Tom Rini wrote:>
> >>> git-subtree-dir: dts/upstream
> >>> git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> >>> ---
> >>> This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> >>> -next branch. To test these changes yourself locally, either use my
> >>> "WIP/14May2024-next" branch or run:
> >>> ./dts/update-dts-subtree.sh pull v6.9-dts
> >>> yourself locally. I intend to wait a few days to apply this to -next, to
> >>> give people time to test.
> >>>
> >>
> >> There are currently more boards/SoCs that use OF_UPSTREAM in master
> >> branch than in next branch, a few Rockchip SoCs and other boards/SoCs.
> >
> > Glad to see more OF_UPSTREAM adoption.
> >
> >> Next dts/upstream sync will probably be good to do together with a merge
> >> of master into next :-)
> >
> > I don't have any particular opinion here and rather leave it upto Tom
> > how he would like to merge stuff.
> >
> >>
> >> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
> >> probably be released shortly after U-Boot v2024.07. So will next sync be
> >> to v6.10-dts if that happens in the U-Boot merge window or do we expect
> >> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
> >> U-Boot merge window?
> >>
> >> Linux kernel typically have all major DT changes in -rc1 and fixes in
> >> later -rcX, so for next branch I would suggest an early sync to a
> >> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
> >> gets released. That should give more time for testing, migration and
> >> cleanup using v6.10 DTs in time for a 2024.10 release.
> >
> > I can see the reasoning for an aggressive DT syncing approach, it has
> > been brought up in the past too. And the major reason for the current
> > moderate sync approach [1] is to limit any DT ABI breakages for
> > U-Boot, we are even prone to breakages with syncs against major Linux
> > kernel releases (eg. v6.10-dts etc.). It has been a long time
> > discussion topic where we have been advocating about requirements for
> > DT ABI stability [2].
> >
> > So having DT syncs done during the merge window will shorten the
> > testing window for developers/maintainers. And more syncs means a
> > multiplicative factor for testing. However, time will tell with more
> > and more platforms adopting OF_UPSTREAM, if there are any real DT ABI
> > breakages seen in the future. But surely if they are very rare then I
> > am open to adopting aggressive DT sync approaches.
>
> I agree that syncing multiple rcX tags may not be that helpful, but an
> approach where maybe rc1, rc2 or rc3 and then the final tag is merged or
> something similar. At least when we can foresee when next Linux version
> will be released close to an U-Boot release. At least early in U-Boot
> release cycle know what Linux version dts/upstream will be targeted.
>
> My main concern is how to best handle new boards and features/drivers.
> E.g. for Rockchip the RK3588 SoC is under active development, new boards
> and features/drivers are actively added/fixed in upstream Linux.
>
> New Rockchip boards have typically been added after board DT have been
> merged into linux maintainer tree. Now if we wait until merge window to
> do a dts/upstream sync, the result may be that it may take up to three
> U-Boot releases until a new board is easily added using dts/upstream.
>
> Another approach could be that we add new boards using !OF_UPSTREAM once
> they are merged into linux maintainer tree. And then migrate the board
> to use OF_UPSTREAM once the board finally ends up in dts/upstream.
>
> But that can also be problematic when board .dts-file start referencing
> nodes/symbols not yet added in the soc .dts-file in dts/upstream.
> Adding the "missing" but maintainer merged soc nodes to the soc
> u-boot.dtsi could be one way to work around such issue.

I would suggest you to then maintain the under development soc
.dts-file in U-Boot too. Since with !OF_UPSTREAM, the soc .dts-file
present in the U-Boot DTS tree (arch/${ARCH}/dts/) will be used
instead of one from dts/upstream. This was especially done to support
use-cases like this via the directory include ordering. You c

Re: [PATCH 1/1] Squashed 'dts/upstream/' changes from b35b9bd1d4ee..7e08733c96c8

2024-05-15 Thread Sumit Garg
Hi Jonas,

On Wed, 15 May 2024 at 13:11, Jonas Karlman  wrote:
>
> Hi Tom,
>
> On 2024-05-14 18:42, Tom Rini wrote:>
> > git-subtree-dir: dts/upstream
> > git-subtree-split: 7e08733c96c84eb323f47e9b248c924e2ac6272a
> > ---
> > This moves OF_UPSTREAM to be tracking the v6.9 release and is for the
> > -next branch. To test these changes yourself locally, either use my
> > "WIP/14May2024-next" branch or run:
> > ./dts/update-dts-subtree.sh pull v6.9-dts
> > yourself locally. I intend to wait a few days to apply this to -next, to
> > give people time to test.
> >
>
> There are currently more boards/SoCs that use OF_UPSTREAM in master
> branch than in next branch, a few Rockchip SoCs and other boards/SoCs.

Glad to see more OF_UPSTREAM adoption.

> Next dts/upstream sync will probably be good to do together with a merge
> of master into next :-)

I don't have any particular opinion here and rather leave it upto Tom
how he would like to merge stuff.

>
> Also what is the expected sync cadence of dts/upstream? Linux v6.10 will
> probably be released shortly after U-Boot v2024.07. So will next sync be
> to v6.10-dts if that happens in the U-Boot merge window or do we expect
> 2024.10 to use v6.9 DTs if the v6.10 release gets delayed and miss the
> U-Boot merge window?
>
> Linux kernel typically have all major DT changes in -rc1 and fixes in
> later -rcX, so for next branch I would suggest an early sync to a
> v6.10-rcX-dts tag, and then sync to the final v6.10-dts tag once v6.10
> gets released. That should give more time for testing, migration and
> cleanup using v6.10 DTs in time for a 2024.10 release.

I can see the reasoning for an aggressive DT syncing approach, it has
been brought up in the past too. And the major reason for the current
moderate sync approach [1] is to limit any DT ABI breakages for
U-Boot, we are even prone to breakages with syncs against major Linux
kernel releases (eg. v6.10-dts etc.). It has been a long time
discussion topic where we have been advocating about requirements for
DT ABI stability [2].

So having DT syncs done during the merge window will shorten the
testing window for developers/maintainers. And more syncs means a
multiplicative factor for testing. However, time will tell with more
and more platforms adopting OF_UPSTREAM, if there are any real DT ABI
breakages seen in the future. But surely if they are very rare then I
am open to adopting aggressive DT sync approaches.

[1] 
https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing
[2] 
https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg02162.html

-Sumit

>
> Regards,
> Jonas


Re: [PATCH 12/13] MIPS: boston: Migrate to OF_UPSTREAM

2024-05-13 Thread Sumit Garg
Hi Jiaxun,

On Mon, 13 May 2024 at 23:43, Jiaxun Yang  wrote:
>
> We can now boot with upstream devicetree.
>
> Signed-off-by: Jiaxun Yang 
> ---
>  arch/mips/Kconfig|   1 +
>  arch/mips/dts/Makefile   |   1 -
>  arch/mips/dts/boston-u-boot.dtsi |  10 ++
>  arch/mips/dts/img,boston.dts | 222 
> ---
>  board/imgtec/boston/MAINTAINERS  |   1 +
>  configs/boston32r2_defconfig |   2 +-
>  configs/boston32r2el_defconfig   |   2 +-
>  configs/boston32r6_defconfig |   2 +-
>  configs/boston32r6el_defconfig   |   2 +-
>  configs/boston64r2_defconfig |   2 +-
>  configs/boston64r2el_defconfig   |   2 +-
>  configs/boston64r6_defconfig |   2 +-
>  configs/boston64r6el_defconfig   |   2 +-
>  13 files changed, 20 insertions(+), 231 deletions(-)
>

Thanks for your efforts although I have a further suggestion below but FWIW:

Reviewed-by: Sumit Garg 

> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 748b5175b2eb..733a8de4fb83 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -146,6 +146,7 @@ config TARGET_BOSTON
> select SUPPORTS_CPU_MIPS64_R2
> select SUPPORTS_CPU_MIPS64_R6
> select SUPPORTS_LITTLE_ENDIAN
> +   imply OF_UPSTREAM
> imply BOOTSTD_FULL
> imply CLK
> imply CLK_BOSTON
> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
> index 14fbce597b9e..5478dcd8d025 100644
> --- a/arch/mips/dts/Makefile
> +++ b/arch/mips/dts/Makefile
> @@ -3,7 +3,6 @@
>  dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
>  dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
>  dtb-$(CONFIG_TARGET_AP152) += ap152.dtb
> -dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
>  dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
>  dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
>  dtb-$(CONFIG_TARGET_XILFPGA) += nexys4ddr.dtb
> diff --git a/arch/mips/dts/boston-u-boot.dtsi 
> b/arch/mips/dts/boston-u-boot.dtsi
> new file mode 100644
> index ..1b0c0a289613
> --- /dev/null
> +++ b/arch/mips/dts/boston-u-boot.dtsi
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +_regs {
> +   compatible = "img,boston-platform-regs", "syscon", "simple-mfd";
> +   bootph-all;
> +};
> +
> +_boston {
> +   bootph-all;
> +};

You can try to push these overrides to upstream DTS as well, so you
won't have to maintain them in U-Boot.

-Sumit

> diff --git a/arch/mips/dts/img,boston.dts b/arch/mips/dts/img,boston.dts
> deleted file mode 100644
> index c1a73963037d..
> --- a/arch/mips/dts/img,boston.dts
> +++ /dev/null
> @@ -1,222 +0,0 @@
> -/dts-v1/;
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -/ {
> -   #address-cells = <1>;
> -   #size-cells = <1>;
> -   compatible = "img,boston";
> -
> -   chosen {
> -   stdout-path = 
> -   };
> -
> -   cpus {
> -   #address-cells = <1>;
> -   #size-cells = <0>;
> -
> -   cpu@0 {
> -   device_type = "cpu";
> -   compatible = "img,mips";
> -   reg = <0>;
> -   clocks = <_boston BOSTON_CLK_CPU>;
> -   };
> -   };
> -
> -   memory@0 {
> -   device_type = "memory";
> -   reg = <0x 0x1000>;
> -   };
> -
> -   gic: interrupt-controller {
> -   compatible = "mti,gic";
> -
> -   interrupt-controller;
> -   #interrupt-cells = <3>;
> -
> -   timer {
> -   compatible = "mti,gic-timer";
> -   interrupts = ;
> -   clocks = <_boston BOSTON_CLK_CPU>;
> -   };
> -   };
> -
> -   pci0: pci@1000 {
> -   status = "disabled";
> -   compatible = "xlnx,axi-pcie-host-1.00.a";
> -   device_type = "pci";
> -   reg = <0x1000 0x200>;
> -
> -   #address-cells = <3>;
> -   #size-cells = <2>;
> -   #interrupt-cells = <1>;
> -
> -   interrupt-parent = <>;
> -   interrupts = ;
> -
> -   ranges = <0x0200 0 0x4000
> - 0x4000 0 0x4000>;
> -
> -   interrupt-map-mask = <0 0 0 7>;
> -   interrupt-map = <0 0 0 1 _intc 0&

Re: [PATCH 11/13] dts/upstream: Add Makefile for MIPS

2024-05-13 Thread Sumit Garg
Hi Jiaxun,

On Mon, 13 May 2024 at 23:43, Jiaxun Yang  wrote:
>
> It is required to make OF_UPSTREAM work.
>
> Signed-off-by: Jiaxun Yang 
> ---
>  dts/upstream/src/mips/Makefile | 14 ++
>  1 file changed, 14 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/dts/upstream/src/mips/Makefile b/dts/upstream/src/mips/Makefile
> new file mode 100644
> index ..9a8f6aa35846
> --- /dev/null
> +++ b/dts/upstream/src/mips/Makefile
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +include $(srctree)/scripts/Makefile.dts
> +
> +targets += $(dtb-y)
> +
> +# Add any required device tree compiler flags here
> +DTC_FLAGS += -a 0x8
> +
> +PHONY += dtbs
> +dtbs: $(addprefix $(obj)/, $(dtb-y))
> +   @:
> +
> +clean-files := */*.dtb */*.dtbo
>
> --
> 2.34.1
>


Re: [PATCH] mach-snapdragon: do carveouts for qcs404 only

2024-05-08 Thread Sumit Garg
On Wed, 8 May 2024 at 18:09, Caleb Connolly  wrote:
>
> Hi Sam,
>
> On 08/05/2024 13:40, Sam Day wrote:
> > Salutations Sumit,
> >
> > On Wednesday, 8 May 2024 at 11:14 AM, Sumit Garg  
> > wrote:
> >
> >>
> >>
> >> Hi Sam,
> >>
> >> On Wed, 8 May 2024 at 00:11, Sam Day m...@samcday.com wrote:
> >>
> >>> The newly introduced carve_out_reserved_memory causes issues when
> >>> U-Boot is chained from the lk2nd bootloader. lk2nd provides a
> >>> simple-framebuffer device and marks the framebuffer region as no-map in
> >>> the supplied /reserved-memory. Consequently, the simple_video driver
> >>> triggers a page fault when it tries to write to this region.
> >>
> >>
> >> How does the corresponding Linux kernel driver handle this?
> >
> > Firstly: I'm something of a middle-man here. I would consider Caleb the 
> > authoritative source on the carveouts stuff (since they wrote it) and 
> > Nikita Travkin the authority on the simplefb handoff (since he originally 
> > wrote it for lk2nd to hand off to Linux simpledrm and then adapted it to 
> > work with U-Boot simplefb).
> >
> > I consulted with Nikita on your first question here. He linked me to this 
> > snippet: 
> > https://elixir.bootlin.com/linux/v6.9-rc7/source/drivers/gpu/drm/tiny/simpledrm.c#L877
> >
> >>   Is the
> >> framebuffer region required to be mapped as normal memory or device
> >> type or something else?
> >
> > So I guess based on the link above, it's just mapped as normal uncached 
> > memory.
> >
> > I tried to do something like this a few days ago in U-Boot, but a) it 
> > doesn't work and b) I have no idea what I'm doing: 
> > https://github.com/samcday/u-boot/commit/c100cb3711ddf5b01601691f3e6a9ec890d9a496

Can you start adding some debug prints as to what might be happening?
Also, look at my proposal below to hook memory mapping properly for
drivers.

> >
> > After talking with Caleb about this for a bit, they suggested the patch you 
> > see here as what I guess could be considered a "stopgap" solution that 
> > hopefully makes it into 2024.07.
> >
> >> Similarly would normal memory type work for
> >> all other reserved memory regions marked as no-map?
> >
> > I'll let Caleb weigh in here. My understanding is that the other regions 
> > *should* be marked as PTE_TYPE_FAULT because otherwise drivers might 
> > inadvertently speculatively access regions that are very much off-limits, 
> > such as TZ app regions.
>
> Right, carving out reserved regions and having the driver handle them is
> theoretically the "correct" thing to do here. But I'm not sure that the
> additional complexity offers much value from a U-Boot context.
>
> If we can teach the armv8 PT/cache code to handle this better, and teach
> all the drivers to map their regions on-demand, this would probably help
> us a lot (especially as right now if you attempt to access dead space
> between peripherals then you'll hang the bus...). But U-Boot is a ways
> away from that.

I am not sure if U-Boot is really that far away although you can say
the infrastructure is not hooked up for Arm. Have a look into
map_physmem() and unmap_physmem() utilized by various drivers which
are actually hooked up on MIPS. So I think the right way to approach
this feature on Qcom platforms is to start hooking up those APIs on
mach-snapdragon to begin with via mmu_set_region_dcache_behaviour()
underneath. We can always go ahead and make it more generic if needed
on other platforms too.

-Sumit


Re: [PATCH] mach-snapdragon: do carveouts for qcs404 only

2024-05-08 Thread Sumit Garg
Hi Sam,

On Wed, 8 May 2024 at 00:11, Sam Day  wrote:
>
> The newly introduced carve_out_reserved_memory causes issues when
> U-Boot is chained from the lk2nd bootloader. lk2nd provides a
> simple-framebuffer device and marks the framebuffer region as no-map in
> the supplied /reserved-memory. Consequently, the simple_video driver
> triggers a page fault when it tries to write to this region.

How does the corresponding Linux kernel driver handle this? Is the
framebuffer region required to be mapped as normal memory or device
type or something else? Similarly would normal memory type work for
all other reserved memory regions marked as no-map?

-Sumit

>
> As per Caleb's advice, this simple patch only does the carveouts for the
> qcs404 SoC for which it was originally designed. The intent is to do the
> carveouts for more Qualcomm SoCs in future.
>
> ---
> I'm not sure if it's feasible to get this in for the 2024.07 release,
> but it'd be great if we could - it's the only thing that breaks U-Boot
> master on msm8916 devices that chain from lk2nd.
>
> Signed-off-by: Sam Day 
> ---
>  arch/arm/mach-snapdragon/board.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-snapdragon/board.c 
> b/arch/arm/mach-snapdragon/board.c
> index 3d5994c878..b439a19ec7 100644
> --- a/arch/arm/mach-snapdragon/board.c
> +++ b/arch/arm/mach-snapdragon/board.c
> @@ -467,10 +467,12 @@ void enable_caches(void)
> gd->arch.tlb_addr = tlb_addr;
> gd->arch.tlb_size = tlb_size;
>
> -   carveout_start = get_timer(0);
> -   /* Takes ~20-50ms on SDM845 */
> -   carve_out_reserved_memory();
> -   debug("carveout time: %lums\n", get_timer(carveout_start));
> -
> +   /* We do the carveouts only for QCS404, for now. */
> +   if (fdt_node_check_compatible(gd->fdt_blob, 0, "qcom,qcs404") == 0) {
> +   carveout_start = get_timer(0);
> +   /* Takes ~20-50ms on SDM845 */
> +   carve_out_reserved_memory();
> +   debug("carveout time: %lums\n", get_timer(carveout_start));
> +   }
> dcache_enable();
>  }
>
> ---
> base-commit: 1c40dda60f5f7e83a6d6f541cf5a57eb7e8ec43c
> change-id: 20240507-qcs404-carveout-only-7a15bbf3fd89
>
> Best regards,
> --
> Sam Day 
>
>


Re: [PATCH 108/149] board: qualcomm: Remove and add needed includes

2024-05-01 Thread Sumit Garg
On Wed, 1 May 2024 at 08:15, Tom Rini  wrote:
>
> Remove  from this board vendor directory and when needed
> add missing include files directly.
>
> Signed-off-by: Tom Rini 
> ---
> Cc: Ramon Fried 
> Cc: Caleb Connolly 
> Cc: Neil Armstrong 
> Cc: Sumit Garg 
> Cc: Jorge Ramirez-Ortiz 
> ---
>  board/qualcomm/dragonboard410c/dragonboard410c.c | 1 -
>  board/qualcomm/dragonboard820c/dragonboard820c.c | 1 -
>  2 files changed, 2 deletions(-)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/board/qualcomm/dragonboard410c/dragonboard410c.c 
> b/board/qualcomm/dragonboard410c/dragonboard410c.c
> index fbbfc0e65e24..bd2e213b3bca 100644
> --- a/board/qualcomm/dragonboard410c/dragonboard410c.c
> +++ b/board/qualcomm/dragonboard410c/dragonboard410c.c
> @@ -6,7 +6,6 @@
>   */
>
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/board/qualcomm/dragonboard820c/dragonboard820c.c 
> b/board/qualcomm/dragonboard820c/dragonboard820c.c
> index ac7de711c588..da59db01 100644
> --- a/board/qualcomm/dragonboard820c/dragonboard820c.c
> +++ b/board/qualcomm/dragonboard820c/dragonboard820c.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 2.34.1
>


Re: [PATCH v4 0/7] Add SE HMBSC board support

2024-04-23 Thread Sumit Garg
On Tue, 23 Apr 2024 at 17:29, Caleb Connolly  wrote:
>
> Applied, thanks.

Thanks.

>
> (b4 didn't seem to detect this series properly, hence the manual mail).
>

Switching my workflow to b4 is on my ToDo list. I hope to do it sooner
rather than later.

-Sumit

> On 12/04/2024 11:54, Sumit Garg wrote:
> > SE HMIBSC board is based on Qcom APQ8016 SoC. One of the major
> > difference from db410c is serial port where HMIBSC board uses UART1 as
> > the debug console with an RS232 port, patch #2 - #5 adds corresponding
> > driver support.
> >
> > Patch #6 adds main HMIBSC board specific bits, features:
> > - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
> > - 2GiB RAM
> > - 64GiB eMMC, SD slot
> > - WiFi and Bluetooth
> > - 2x Host, 1x Device USB port
> > - HDMI
> > - Discrete TPM2 chip over SPI
> >
> > Features enabled in U-Boot:
> > - RAUC updates (refer [2] for more details)
> > - Environment protection
> > - USB based ethernet adaptors
> >
> > Feedback is very much welcome.
> >
> > Changes in v4:
> > - Rebased on top of qcom-main [4].
> > - Split out board DTS patch as #6.
> > - Convert to text based environment as hmibsc.env.
> > - MMC regression has been reported for qcom-main branch here [5].
> > - Collected further review tag.
> >
> > Changes in v3:
> > - Rebased on top of qcom-next [1].
> > - Collected some review tags.
> > - Incorporated misc. comments from Caleb and Stephen.
> > - Split patch#4 as requested.
> > - Linux HMIBSC board DTS has already been reviewed here [3], I have
> >incorporated that for U-Boot too.
> >
> > Changes in v2:
> > - Rebased on top on qcom-next [1].
> > - Added patch#1 as a fix for generic qcom board support.
> > - Added patch#4 to enable driving GPIO pins based on pinctrl
> >configuration. This replaces the custom GPIO configuration.
> > - Added proper DTS file for HMIBSC board based on Linux DT pattern.
> > - Merged board support patches into a single patch#5.
> >
> > [1] 
> > https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-next?ref_type=heads
> > [2] https://rauc.readthedocs.io/en/latest/
> > [3] 
> > https://lore.kernel.org/linux-kernel/20240403043416.3800259-4-sumit.g...@linaro.org/
> > [4] 
> > https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-main/?ref_type=heads
> > [5] 
> > https://lore.kernel.org/all/cafa6wyo+3vroudfuvh390taviqx8pmqroqdtsn0yu6bd5yy...@mail.gmail.com/
> >
> > Sumit Garg (7):
> >qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default
> >apq8016: Add support for UART1 clocks and pinmux
> >serial_msm: Enable RS232 flow control
> >pinctrl: qcom: Add support for driving GPIO pins output
> >pinctrl: qcom: apq8016: Add GPIO pinctrl function
> >arm: dts: qcom: Add Schneider HMIBSC board dts
> >board: add support for Schneider HMIBSC board
> >
> >   arch/arm/Kconfig  |   2 +-
> >   arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
> >   board/schneider/hmibsc/MAINTAINERS|   6 +
> >   board/schneider/hmibsc/hmibsc.env |  40 ++
> >   configs/hmibsc_defconfig  |  87 
> >   doc/board/index.rst   |   1 +
> >   doc/board/schneider/hmibsc.rst|  45 ++
> >   doc/board/schneider/index.rst |   9 +
> >   drivers/clk/qcom/clock-apq8016.c  |  38 +-
> >   drivers/pinctrl/qcom/pinctrl-apq8016.c|   2 +
> >   drivers/pinctrl/qcom/pinctrl-qcom.c   |  25 +-
> >   drivers/serial/serial_msm.c   |  24 +-
> >   include/configs/hmibsc.h  |  16 +
> >   13 files changed, 760 insertions(+), 26 deletions(-)
> >   create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts
> >   create mode 100644 board/schneider/hmibsc/MAINTAINERS
> >   create mode 100644 board/schneider/hmibsc/hmibsc.env
> >   create mode 100644 configs/hmibsc_defconfig
> >   create mode 100644 doc/board/schneider/hmibsc.rst
> >   create mode 100644 doc/board/schneider/index.rst
> >   create mode 100644 include/configs/hmibsc.h
> >
>
> --
> // Caleb (they/them)


Re: [PATCH 0/3] qcom: switch to OF_UPSTREAM

2024-04-22 Thread Sumit Garg
On Thu, 18 Apr 2024 at 10:24, Caleb Connolly  wrote:
>
> This series does the initial switch to OF_UPSTREAM for Qualcomm
> platforms. The DT files we have in U-Boot are outdated by now, so drop
> them and move to upstream.
>
> Patch 2 drops all the Qualcomm dts files that are now provided in
> dts/upstream. As some of the files exceed the 100k size limit by
> themselves I thought it would be easier to just lump them together
> rather than trying to split them up.
>
> The associated qcom headers will be cleaned up in future patches.
>
> ---
> Caleb Connolly (3):
>   mach-snapdragon: use OF_UPSTREAM
>   arm: dts: drop qcom dts files
>   qcom_defconfig: set SYS_INIT_SP_BSS_OFFSET
>

Reviewed-by: Sumit Garg 

-Sumit

>  MAINTAINERS |4 -
>  arch/arm/Kconfig|1 +
>  arch/arm/dts/apq8016-sbc.dts|  729 
>  arch/arm/dts/apq8096-db820c.dts | 1137 --
>  arch/arm/dts/msm8916-pm8916.dtsi|  157 -
>  arch/arm/dts/msm8916.dtsi   | 2702 -
>  arch/arm/dts/msm8996.dtsi   | 3884 --
>  arch/arm/dts/pm8916.dtsi|  178 -
>  arch/arm/dts/pm8994.dtsi|  152 -
>  arch/arm/dts/pm8998.dtsi|  130 -
>  arch/arm/dts/pmi8994.dtsi   |   65 -
>  arch/arm/dts/pmi8998.dtsi   |   98 -
>  arch/arm/dts/pms405.dtsi|  149 -
>  arch/arm/dts/qcs404-evb-4000.dts|   96 -
>  arch/arm/dts/qcs404-evb.dtsi|  389 --
>  arch/arm/dts/qcs404.dtsi| 1829 -
>  arch/arm/dts/sdm845-db845c.dts  | 1190 --
>  arch/arm/dts/sdm845-samsung-starqltechn.dts |  460 ---
>  arch/arm/dts/sdm845-wcd9340.dtsi|   86 -
>  arch/arm/dts/sdm845.dtsi| 5752 
> ---
>  configs/dragonboard410c_defconfig   |2 +-
>  configs/dragonboard820c_defconfig   |2 +-
>  configs/qcom_defconfig  |3 +-
>  23 files changed, 5 insertions(+), 19190 deletions(-)
> ---
> base-commit: d5460b082cd6afd0e07c0ec0e5a82d1af8dc09f7
>
> // Caleb (they/them)
>


Re: [PATCH v3 1/3] clk: imx8mm: Add support for PCIe clocks

2024-04-21 Thread Sumit Garg
Hi Tim,

On Fri, 19 Apr 2024 at 08:29, Tim Harvey  wrote:
>
> Add support for PCIe clocks required to enable PCIe support on
> iMX8MM SoC.
>
> Signed-off-by: Tim Harvey 
> ---
> v3: wrap pcie clk config around IS_ENABLED to avoid SPL growth as
> suggested by Marek
> ---
>  drivers/clk/imx/clk-imx8mm.c | 27 +++
>  1 file changed, 27 insertions(+)
>

Although I was at EOSS last week, it is really nice to see more iMX
SoCs adopting the modern PCIe DW iMX driver.

-Sumit

> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index b5c253e49663..1a00dd1d287b 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -66,6 +66,17 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m", 
> "sys_pll1_160m", "sys_
>  static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m", 
> "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
>  "video_pll1_out", "audio_pll2_out", 
> "sys_pll1_133m", };
>
> +#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
> +static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m", 
> "sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
> +  "sys_pll1_800m", 
> "sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
> +
> +static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m", 
> "sys_pll2_100m", "sys_pll2_500m", "clk_ext1", "clk_ext2",
> + "clk_ext3", "clk_ext4", 
> "sys_pll1_400m", };
> +
> +static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m", 
> "sys_pll2_200m", "sys_pll2_50m", "sys_pll3_out",
> + "sys_pll2_100m", 
> "sys_pll1_80m", "sys_pll1_160m", "sys_pll1_200m", };
> +#endif
> +
>  #ifndef CONFIG_SPL_BUILD
>  static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m", 
> "sys_pll1_160m", "sys_pll1_40m",
>  "sys_pll3_out", "clk_ext1", 
> "sys_pll1_80m", "video_pll1_out", };
> @@ -256,6 +267,17 @@ static int imx8mm_clk_probe(struct udevice *dev)
> imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base + 
> 0x8b80));
>
> /* IP */
> +#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
> +   clk_dm(IMX8MM_CLK_PCIE1_CTRL,
> +  imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
> +  base + 0xa300));
> +   clk_dm(IMX8MM_CLK_PCIE1_PHY,
> +  imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
> +  base + 0xa380));
> +   clk_dm(IMX8MM_CLK_PCIE1_AUX,
> +  imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
> +  base + 0xa400));
> +#endif
> clk_dm(IMX8MM_CLK_USDHC1,
>imx8m_clk_composite("usdhc1", imx8mm_usdhc1_sels,
>base + 0xac00));
> @@ -339,6 +361,11 @@ static int imx8mm_clk_probe(struct udevice *dev)
>imx_clk_gate4("pwm4_root_clk", "pwm4", base + 0x42b0, 0));
>  #endif
>
> +#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
> +   clk_dm(IMX8MM_CLK_PCIE1_ROOT,
> +  imx_clk_gate4("pcie1_root_clk", "pcie1_ctrl", base + 0x4250, 
> 0));
> +#endif
> +
>  #if CONFIG_IS_ENABLED(DM_SPI)
> clk_dm(IMX8MM_CLK_ECSPI1,
>imx8m_clk_composite("ecspi1", imx8mm_ecspi1_sels, base + 
> 0xb280));
> --
> 2.25.1
>


Re: [PATCH v4 0/7] Add SE HMBSC board support

2024-04-19 Thread Sumit Garg
Hi Caleb,

On Fri, 12 Apr 2024 at 02:54, Sumit Garg  wrote:
>
> SE HMIBSC board is based on Qcom APQ8016 SoC. One of the major
> difference from db410c is serial port where HMIBSC board uses UART1 as
> the debug console with an RS232 port, patch #2 - #5 adds corresponding
> driver support.
>
> Patch #6 adds main HMIBSC board specific bits, features:
> - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
> - 2GiB RAM
> - 64GiB eMMC, SD slot
> - WiFi and Bluetooth
> - 2x Host, 1x Device USB port
> - HDMI
> - Discrete TPM2 chip over SPI
>
> Features enabled in U-Boot:
> - RAUC updates (refer [2] for more details)
> - Environment protection
> - USB based ethernet adaptors
>
> Feedback is very much welcome.
>
> Changes in v4:
> - Rebased on top of qcom-main [4].
> - Split out board DTS patch as #6.
> - Convert to text based environment as hmibsc.env.
> - MMC regression has been reported for qcom-main branch here [5].
> - Collected further review tag.

I haven't seen any further comments on this series. Can you help pick it up?

-Sumit

>
> Changes in v3:
> - Rebased on top of qcom-next [1].
> - Collected some review tags.
> - Incorporated misc. comments from Caleb and Stephen.
> - Split patch#4 as requested.
> - Linux HMIBSC board DTS has already been reviewed here [3], I have
>   incorporated that for U-Boot too.
>
> Changes in v2:
> - Rebased on top on qcom-next [1].
> - Added patch#1 as a fix for generic qcom board support.
> - Added patch#4 to enable driving GPIO pins based on pinctrl
>   configuration. This replaces the custom GPIO configuration.
> - Added proper DTS file for HMIBSC board based on Linux DT pattern.
> - Merged board support patches into a single patch#5.
>
> [1] 
> https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-next?ref_type=heads
> [2] https://rauc.readthedocs.io/en/latest/
> [3] 
> https://lore.kernel.org/linux-kernel/20240403043416.3800259-4-sumit.g...@linaro.org/
> [4] 
> https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-main/?ref_type=heads
> [5] 
> https://lore.kernel.org/all/cafa6wyo+3vroudfuvh390taviqx8pmqroqdtsn0yu6bd5yy...@mail.gmail.com/
>
> Sumit Garg (7):
>   qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default
>   apq8016: Add support for UART1 clocks and pinmux
>   serial_msm: Enable RS232 flow control
>   pinctrl: qcom: Add support for driving GPIO pins output
>   pinctrl: qcom: apq8016: Add GPIO pinctrl function
>   arm: dts: qcom: Add Schneider HMIBSC board dts
>   board: add support for Schneider HMIBSC board
>
>  arch/arm/Kconfig  |   2 +-
>  arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
>  board/schneider/hmibsc/MAINTAINERS|   6 +
>  board/schneider/hmibsc/hmibsc.env |  40 ++
>  configs/hmibsc_defconfig  |  87 
>  doc/board/index.rst   |   1 +
>  doc/board/schneider/hmibsc.rst|  45 ++
>  doc/board/schneider/index.rst |   9 +
>  drivers/clk/qcom/clock-apq8016.c  |  38 +-
>  drivers/pinctrl/qcom/pinctrl-apq8016.c|   2 +
>  drivers/pinctrl/qcom/pinctrl-qcom.c   |  25 +-
>  drivers/serial/serial_msm.c   |  24 +-
>  include/configs/hmibsc.h  |  16 +
>  13 files changed, 760 insertions(+), 26 deletions(-)
>  create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts
>  create mode 100644 board/schneider/hmibsc/MAINTAINERS
>  create mode 100644 board/schneider/hmibsc/hmibsc.env
>  create mode 100644 configs/hmibsc_defconfig
>  create mode 100644 doc/board/schneider/hmibsc.rst
>  create mode 100644 doc/board/schneider/index.rst
>  create mode 100644 include/configs/hmibsc.h
>
> --
> 2.34.1
>


[PATCH v4 7/7] board: add support for Schneider HMIBSC board

2024-04-12 Thread Sumit Garg
Support for Schneider Electric HMIBSC. Features:
- Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
- 2GiB RAM
- 64GiB eMMC, SD slot
- WiFi and Bluetooth
- 2x Host, 1x Device USB port
- HDMI
- Discrete TPM2 chip over SPI

Features enabled in U-Boot:
- RAUC updates
- Environment protection
- USB based ethernet adaptors

Signed-off-by: Sumit Garg 
---
 board/schneider/hmibsc/MAINTAINERS |  6 +++
 board/schneider/hmibsc/hmibsc.env  | 40 ++
 configs/hmibsc_defconfig   | 87 ++
 doc/board/index.rst|  1 +
 doc/board/schneider/hmibsc.rst | 45 
 doc/board/schneider/index.rst  |  9 
 include/configs/hmibsc.h   | 16 ++
 7 files changed, 204 insertions(+)
 create mode 100644 board/schneider/hmibsc/MAINTAINERS
 create mode 100644 board/schneider/hmibsc/hmibsc.env
 create mode 100644 configs/hmibsc_defconfig
 create mode 100644 doc/board/schneider/hmibsc.rst
 create mode 100644 doc/board/schneider/index.rst
 create mode 100644 include/configs/hmibsc.h

diff --git a/board/schneider/hmibsc/MAINTAINERS 
b/board/schneider/hmibsc/MAINTAINERS
new file mode 100644
index 000..0f31bbda966
--- /dev/null
+++ b/board/schneider/hmibsc/MAINTAINERS
@@ -0,0 +1,6 @@
+HMIBSC BOARD
+M: Sumit Garg 
+S: Maintained
+F: board/schneider/hmibsc/
+F: include/configs/hmibsc.h
+F: configs/hmibsc_defconfig
diff --git a/board/schneider/hmibsc/hmibsc.env 
b/board/schneider/hmibsc/hmibsc.env
new file mode 100644
index 000..da3d892f91d
--- /dev/null
+++ b/board/schneider/hmibsc/hmibsc.env
@@ -0,0 +1,40 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+loadaddr=0x9000
+bootcmd=
+   echo "Booting RAUC A/B system";
+   setenv devtype mmc; setenv devnum 0;
+   test -n "${BOOT_ORDER}" || setenv BOOT_ORDER "A B";
+   test -n "${BOOT_A_LEFT}" || setenv BOOT_A_LEFT 3;
+   test -n "${BOOT_B_LEFT}" || setenv BOOT_B_LEFT 3;
+   setenv raucslot;
+   for BOOT_SLOT in "${BOOT_ORDER}"; do
+   if test "x${raucslot}" != "x"; then
+   echo "skip remaining slots...";
+   elif test "x${BOOT_SLOT}" = "xA"; then
+   if test ${BOOT_A_LEFT} -gt 0; then
+   setexpr BOOT_A_LEFT ${BOOT_A_LEFT} - 1;
+   echo "Found valid RAUC slot A";
+   setenv raucslot "rauc.slot=A";
+   setenv raucpart A; setenv distro_bootpart 6;
+   fi;
+   elif test "x${BOOT_SLOT}" = "xB"; then
+   if test ${BOOT_B_LEFT} -gt 0; then
+   setexpr BOOT_B_LEFT ${BOOT_B_LEFT} - 1;
+   echo "Found valid RAUC slot B";
+   setenv raucslot "rauc.slot=B";
+   setenv raucpart B; setenv distro_bootpart 7;
+   fi;
+   fi;
+   done;
+   if test -n "${raucslot}"; then
+   setenv bootargs console=ttyMSM1 
root=PARTLABEL=rootfs_${raucpart} rw rootwait ${raucslot};
+   saveenv;
+   else
+   echo "No valid RAUC slot found. Resetting tries to 3";
+   setenv BOOT_A_LEFT 3;
+   setenv BOOT_B_LEFT 3;
+   saveenv;
+   reset;
+   fi;
+   load ${devtype} ${devnum}:${distro_bootpart} ${loadaddr} /boot/fitImage 
&& bootm;
diff --git a/configs/hmibsc_defconfig b/configs/hmibsc_defconfig
new file mode 100644
index 000..a07689894ef
--- /dev/null
+++ b/configs/hmibsc_defconfig
@@ -0,0 +1,87 @@
+CONFIG_ARM=y
+CONFIG_SYS_VENDOR="schneider"
+CONFIG_SYS_BOARD="hmibsc"
+CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
+CONFIG_ARCH_SNAPDRAGON=y
+CONFIG_TEXT_BASE=0x8f60
+CONFIG_SYS_MALLOC_LEN=0x802000
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8007fff0
+CONFIG_ENV_SIZE=0x2000
+CONFIG_ENV_OFFSET=0x0
+CONFIG_DEFAULT_DEVICE_TREE="apq8016-schneider-hmibsc"
+# CONFIG_OF_UPSTREAM is not set
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_IDENT_STRING="\nSchneider Electric-HMIBSC"
+CONFIG_SYS_LOAD_ADDR=0x8008
+CONFIG_REMAKE_ELF=y
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_FIT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_CBSIZE=2048
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_SYS_PROMPT="hmibsc => "
+CONFIG_SYS_MAXARGS=64
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_FS_GENERIC=y
+# CONFIG_CMD_IMI is not set
+CONFIG_CMD_MD5SUM=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PART

[PATCH v4 6/7] arm: dts: qcom: Add Schneider HMIBSC board dts

2024-04-12 Thread Sumit Garg
Schneider HMIBSC board dts has already been reviewed upstream on the
linux-arm-msm mailing list. So once it comes through the Linux kernel
release cycle into the U-Boot dts/upstream subtree, a switch to
OF_UPSTREAM can be made. For the time being maintain the U-Boot copy.

Link: 
https://lore.kernel.org/linux-kernel/20240403043416.3800259-4-sumit.g...@linaro.org/
Signed-off-by: Sumit Garg 
---
 arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
 1 file changed, 491 insertions(+)
 create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts

diff --git a/arch/arm/dts/apq8016-schneider-hmibsc.dts 
b/arch/arm/dts/apq8016-schneider-hmibsc.dts
new file mode 100644
index 000..75c6137e5a1
--- /dev/null
+++ b/arch/arm/dts/apq8016-schneider-hmibsc.dts
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include "msm8916-pm8916.dtsi"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Schneider Electric HMIBSC Board";
+   compatible = "schneider,apq8016-hmibsc", "qcom,apq8016";
+
+   aliases {
+   i2c1 = _i2c6;
+   i2c3 = _i2c4;
+   i2c4 = _i2c3;
+   mmc0 = _1; /* eMMC */
+   mmc1 = _2; /* SD card */
+   serial0 = _uart1;
+   serial1 = _uart2;
+   spi0 = _spi5;
+   usid0 = _0;
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   autorepeat;
+   pinctrl-0 = <_key_volp_n_default>;
+   pinctrl-names = "default";
+
+   button {
+   label = "Volume Up";
+   linux,code = ;
+   gpios = < 107 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-0 = <_mpps_leds>;
+   pinctrl-names = "default";
+
+   led-1 {
+   function = LED_FUNCTION_WLAN;
+   color = ;
+   gpios = <_mpps 2 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "phy0tx";
+   default-state = "off";
+   };
+
+   led-2 {
+   function = LED_FUNCTION_BLUETOOTH;
+   color = ;
+   gpios = <_mpps 3 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "bluetooth-power";
+   default-state = "off";
+   };
+   };
+
+   memory@8000 {
+   reg = <0 0x8000 0 0x4000>;
+   };
+
+   reserved-memory {
+   ramoops@bff0 {
+   compatible = "ramoops";
+   reg = <0x0 0xbff0 0x0 0x10>;
+   record-size = <0x2>;
+   console-size = <0x2>;
+   ftrace-size = <0x2>;
+   ecc-size = <16>;
+   };
+   };
+
+   usb-hub {
+   compatible = "smsc,usb3503";
+   reset-gpios = <_gpios 1 GPIO_ACTIVE_LOW>;
+   initial-mode = <1>;
+   };
+
+   usb_id: usb-id {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpios = < 110 GPIO_ACTIVE_HIGH>;
+   pinctrl-0 = <_id_default>;
+   pinctrl-names = "default";
+   };
+};
+
+_i2c3 {
+   status = "okay";
+
+   eeprom@50 {
+   compatible = "atmel,24c32";
+   reg = <0x50>;
+   };
+};
+
+_i2c4 {
+   status = "okay";
+
+   adv_bridge: bridge@39 {
+   compatible = "adi,adv7533";
+   reg = <0x39>;
+   interrupts-extended = < 31 IRQ_TYPE_EDGE_FALLING>;
+
+   adi,dsi-lanes = <4>;
+   clocks = < RPM_SMD_BB_CLK2>;
+   clock-names = "cec";
+   pd-gpios = < 32 GPIO_ACTIVE_HIGH>;
+
+   avdd-supply = <_l6>;
+   a2vdd-supply = <_l6>;
+   dvdd-supply = <_l6>;
+   pvdd-supply = <_

[PATCH v4 5/7] pinctrl: qcom: apq8016: Add GPIO pinctrl function

2024-04-12 Thread Sumit Garg
Add GPIO pinctrl function to enable driving GPIO pins as output low or
high.

Signed-off-by: Sumit Garg 
---
 drivers/pinctrl/qcom/pinctrl-apq8016.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c 
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index 1ee8b7db1a2..b14a8921af4 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -29,6 +29,7 @@ static const char * const msm_pinctrl_pins[] = {
 };
 
 static const struct pinctrl_function msm_pinctrl_functions[] = {
+   {"gpio", 0},
{"blsp_uart1", 2},
{"blsp_uart2", 2},
 };
-- 
2.34.1



[PATCH v4 4/7] pinctrl: qcom: Add support for driving GPIO pins output

2024-04-12 Thread Sumit Garg
Add support for driving the GPIO pins as output low or high.

Signed-off-by: Sumit Garg 
---
 drivers/pinctrl/qcom/pinctrl-qcom.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c 
b/drivers/pinctrl/qcom/pinctrl-qcom.c
index 909e566acf5..e68971b37ff 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcom.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
@@ -29,15 +29,24 @@ struct msm_pinctrl_priv {
 #define GPIO_CONFIG_REG(priv, x) \
(qcom_pin_offset((priv)->data->pin_data.pin_offsets, x))
 
-#define TLMM_GPIO_PULL_MASK GENMASK(1, 0)
-#define TLMM_FUNC_SEL_MASK GENMASK(5, 2)
-#define TLMM_DRV_STRENGTH_MASK GENMASK(8, 6)
-#define TLMM_GPIO_DISABLE BIT(9)
+#define GPIO_IN_OUT_REG(priv, x) \
+   (GPIO_CONFIG_REG(priv, x) + 0x4)
+
+#define TLMM_GPIO_PULL_MASKGENMASK(1, 0)
+#define TLMM_FUNC_SEL_MASK GENMASK(5, 2)
+#define TLMM_DRV_STRENGTH_MASK GENMASK(8, 6)
+#define TLMM_GPIO_OUTPUT_MASK  BIT(1)
+#define TLMM_GPIO_OE_MASK  BIT(9)
+
+/* GPIO register shifts. */
+#define GPIO_OUT_SHIFT 1
 
 static const struct pinconf_param msm_conf_params[] = {
{ "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 2 },
{ "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
{ "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 3 },
+   { "output-high", PIN_CONFIG_OUTPUT, 1, },
+   { "output-low", PIN_CONFIG_OUTPUT, 0, },
 };
 
 static int msm_get_functions_count(struct udevice *dev)
@@ -90,7 +99,7 @@ static int msm_pinmux_set(struct udevice *dev, unsigned int 
pin_selector,
return 0;
 
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
-   TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE, func << 2);
+   TLMM_FUNC_SEL_MASK | TLMM_GPIO_OE_MASK, func << 2);
return 0;
 }
 
@@ -117,6 +126,12 @@ static int msm_pinconf_set(struct udevice *dev, unsigned 
int pin_selector,
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, 
pin_selector),
TLMM_GPIO_PULL_MASK, argument);
break;
+   case PIN_CONFIG_OUTPUT:
+   writel(argument << GPIO_OUT_SHIFT,
+  priv->base + GPIO_IN_OUT_REG(priv, pin_selector));
+   setbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
+TLMM_GPIO_OE_MASK);
+   break;
default:
return 0;
}
-- 
2.34.1



[PATCH v4 3/7] serial_msm: Enable RS232 flow control

2024-04-12 Thread Sumit Garg
SE HMIBSC board debug console requires RS232 flow control, so enable
corresponding support if RS232 gpios are present.

Reviewed-by: Caleb Connolly 
Signed-off-by: Sumit Garg 
---
 drivers/serial/serial_msm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index 4de10e75191..3142ecf7362 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -53,10 +53,11 @@
 #define UARTDM_TF   0x100 /* UART Transmit FIFO register */
 #define UARTDM_RF   0x140 /* UART Receive FIFO register */
 
-#define UART_DM_CLK_RX_TX_BIT_RATE 0xCC
-#define MSM_BOOT_UART_DM_8_N_1_MODE 0x34
-#define MSM_BOOT_UART_DM_CMD_RESET_RX 0x10
-#define MSM_BOOT_UART_DM_CMD_RESET_TX 0x20
+#define UART_DM_CLK_RX_TX_BIT_RATE 0xCC
+#define MSM_BOOT_UART_DM_8_N_1_MODE0x34
+#define MSM_BOOT_UART_DM_CMD_RESET_RX  0x10
+#define MSM_BOOT_UART_DM_CMD_RESET_TX  0x20
+#define MSM_UART_MR1_RX_RDY_CTLBIT(7)
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -182,7 +183,9 @@ static void uart_dm_init(struct msm_serial_data *priv)
mdelay(5);
 
writel(priv->clk_bit_rate, priv->base + UARTDM_CSR);
-   writel(0x0, priv->base + UARTDM_MR1);
+
+   /* Enable RS232 flow control to support RS232 db9 connector */
+   writel(MSM_UART_MR1_RX_RDY_CTL, priv->base + UARTDM_MR1);
writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2);
writel(MSM_BOOT_UART_DM_CMD_RESET_RX, priv->base + UARTDM_CR);
writel(MSM_BOOT_UART_DM_CMD_RESET_TX, priv->base + UARTDM_CR);
-- 
2.34.1



[PATCH v4 2/7] apq8016: Add support for UART1 clocks and pinmux

2024-04-12 Thread Sumit Garg
SE HMIBSC board uses UART1 as the main debug console, so add
corresponding clocks and pinmux support. Along with that update
instructions to enable clocks for debug UART support.

Reviewed-by: Caleb Connolly 
Signed-off-by: Sumit Garg 
---
 drivers/clk/qcom/clock-apq8016.c   | 38 ++
 drivers/pinctrl/qcom/pinctrl-apq8016.c |  1 +
 drivers/serial/serial_msm.c| 11 ++--
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index 5a5868169c8..9556b94774a 100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -31,7 +31,8 @@
 #define BLSP1_AHB_CBCR 0x1008
 
 /* Uart clock control registers */
-#define BLSP1_UART2_BCR(0x3028)
+#define BLSP1_UART1_APPS_CBCR  (0x203C)
+#define BLSP1_UART1_APPS_CMD_RCGR  (0x2044)
 #define BLSP1_UART2_APPS_CBCR  (0x302C)
 #define BLSP1_UART2_APPS_CMD_RCGR  (0x3034)
 
@@ -52,7 +53,7 @@ static struct vote_clk gcc_blsp1_ahb_clk = {
 };
 
 /* SDHCI */
-static int clk_init_sdc(struct msm_clk_priv *priv, int slot, uint rate)
+static int apq8016_clk_init_sdc(struct msm_clk_priv *priv, int slot, uint rate)
 {
int div = 15; /* 100MHz default */
 
@@ -70,20 +71,35 @@ static int clk_init_sdc(struct msm_clk_priv *priv, int 
slot, uint rate)
 }
 
 /* UART: 115200 */
-int apq8016_clk_init_uart(phys_addr_t base)
+int apq8016_clk_init_uart(phys_addr_t base, unsigned long id)
 {
+   u32 cmd_rcgr, apps_cbcr;
+
+   switch (id) {
+   case GCC_BLSP1_UART1_APPS_CLK:
+   cmd_rcgr = BLSP1_UART1_APPS_CMD_RCGR;
+   apps_cbcr = BLSP1_UART1_APPS_CBCR;
+   break;
+   case GCC_BLSP1_UART2_APPS_CLK:
+   cmd_rcgr = BLSP1_UART2_APPS_CMD_RCGR;
+   apps_cbcr = BLSP1_UART2_APPS_CBCR;
+   break;
+   default:
+   return 0;
+   }
+
/* Enable AHB clock */
clk_enable_vote_clk(base, _blsp1_ahb_clk);
 
/* 7372800 uart block clock @ GPLL0 */
-   clk_rcg_set_rate_mnd(base, BLSP1_UART2_APPS_CMD_RCGR, 1, 144, 15625,
-CFG_CLK_SRC_GPLL0, 16);
+   clk_rcg_set_rate_mnd(base, cmd_rcgr, 1, 144, 15625, CFG_CLK_SRC_GPLL0,
+16);
 
/* Vote for gpll0 clock */
clk_enable_gpll0(base, _vote_clk);
 
/* Enable core clk */
-   clk_enable_cbc(base + BLSP1_UART2_APPS_CBCR);
+   clk_enable_cbc(base + apps_cbcr);
 
return 0;
 }
@@ -94,14 +110,12 @@ static ulong apq8016_clk_set_rate(struct clk *clk, ulong 
rate)
 
switch (clk->id) {
case GCC_SDCC1_APPS_CLK: /* SDC1 */
-   return clk_init_sdc(priv, 0, rate);
-   break;
+   return apq8016_clk_init_sdc(priv, 0, rate);
case GCC_SDCC2_APPS_CLK: /* SDC2 */
-   return clk_init_sdc(priv, 1, rate);
-   break;
+   return apq8016_clk_init_sdc(priv, 1, rate);
+   case GCC_BLSP1_UART1_APPS_CLK: /* UART1 */
case GCC_BLSP1_UART2_APPS_CLK: /* UART2 */
-   return apq8016_clk_init_uart(priv->base);
-   break;
+   return apq8016_clk_init_uart(priv->base, clk->id);
default:
return 0;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c 
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index a9a00f4b081..1ee8b7db1a2 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -29,6 +29,7 @@ static const char * const msm_pinctrl_pins[] = {
 };
 
 static const struct pinctrl_function msm_pinctrl_functions[] = {
+   {"blsp_uart1", 2},
{"blsp_uart2", 2},
 };
 
diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index ac4280c6c4c..4de10e75191 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -248,12 +248,17 @@ static struct msm_serial_data init_serial_data = {
 #include 
 
 /* Uncomment to turn on UART clocks when debugging U-Boot as aboot on MSM8916 
*/
-//int apq8016_clk_init_uart(phys_addr_t gcc_base);
+//int apq8016_clk_init_uart(phys_addr_t gcc_base, unsigned long id);
 
 static inline void _debug_uart_init(void)
 {
-   /* Uncomment to turn on UART clocks when debugging U-Boot as aboot on 
MSM8916 */
-   //apq8016_clk_init_uart(0x180);
+   /*
+* Uncomment to turn on UART clocks when debugging U-Boot as aboot
+* on MSM8916. Supported debug UART clock IDs:
+*   - db410c: GCC_BLSP1_UART2_APPS_CLK
+*   - HMIBSC: GCC_BLSP1_UART1_APPS_CLK
+*/
+   //apq8016_clk_init_uart(0x180, );
uart_dm_init(_serial_data);
 }
 
-- 
2.34.1



[PATCH v4 1/7] qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default

2024-04-12 Thread Sumit Garg
Enabling LINUX_KERNEL_IMAGE_HEADER by default doesn't allow
ENABLE_ARM_SOC_BOOT0_HOOK to work properly on db410c when U-Boot is
loaded as a first stage bootloader. It leads to secondary CPUs bringup
failure and later causing the Linux kernel to freeze.

So fix it via selectively enabling LINUX_KERNEL_IMAGE_HEADER where it's
actually required.

Fixes: 059d526af312 ("mach-snapdragon: generalise board support")
Reviewed-by: Caleb Connolly 
Signed-off-by: Sumit Garg 
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 23ee25269a2..1d451c46d32 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1088,7 +1088,7 @@ config ARCH_SNAPDRAGON
select BOARD_LATE_INIT
select OF_BOARD
select SAVE_PREV_BL_FDT_ADDR
-   select LINUX_KERNEL_IMAGE_HEADER
+   select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
imply CMD_DM
 
 config ARCH_SOCFPGA
-- 
2.34.1



[PATCH v4 0/7] Add SE HMBSC board support

2024-04-12 Thread Sumit Garg
SE HMIBSC board is based on Qcom APQ8016 SoC. One of the major
difference from db410c is serial port where HMIBSC board uses UART1 as
the debug console with an RS232 port, patch #2 - #5 adds corresponding
driver support.

Patch #6 adds main HMIBSC board specific bits, features:
- Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
- 2GiB RAM
- 64GiB eMMC, SD slot
- WiFi and Bluetooth
- 2x Host, 1x Device USB port
- HDMI
- Discrete TPM2 chip over SPI

Features enabled in U-Boot:
- RAUC updates (refer [2] for more details)
- Environment protection
- USB based ethernet adaptors

Feedback is very much welcome.

Changes in v4:
- Rebased on top of qcom-main [4].
- Split out board DTS patch as #6.
- Convert to text based environment as hmibsc.env.
- MMC regression has been reported for qcom-main branch here [5].
- Collected further review tag.

Changes in v3:
- Rebased on top of qcom-next [1].
- Collected some review tags.
- Incorporated misc. comments from Caleb and Stephen.
- Split patch#4 as requested.
- Linux HMIBSC board DTS has already been reviewed here [3], I have
  incorporated that for U-Boot too.

Changes in v2:
- Rebased on top on qcom-next [1].
- Added patch#1 as a fix for generic qcom board support.
- Added patch#4 to enable driving GPIO pins based on pinctrl
  configuration. This replaces the custom GPIO configuration.
- Added proper DTS file for HMIBSC board based on Linux DT pattern.
- Merged board support patches into a single patch#5.

[1] 
https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-next?ref_type=heads
[2] https://rauc.readthedocs.io/en/latest/
[3] 
https://lore.kernel.org/linux-kernel/20240403043416.3800259-4-sumit.g...@linaro.org/
[4] 
https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-main/?ref_type=heads
[5] 
https://lore.kernel.org/all/cafa6wyo+3vroudfuvh390taviqx8pmqroqdtsn0yu6bd5yy...@mail.gmail.com/

Sumit Garg (7):
  qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default
  apq8016: Add support for UART1 clocks and pinmux
  serial_msm: Enable RS232 flow control
  pinctrl: qcom: Add support for driving GPIO pins output
  pinctrl: qcom: apq8016: Add GPIO pinctrl function
  arm: dts: qcom: Add Schneider HMIBSC board dts
  board: add support for Schneider HMIBSC board

 arch/arm/Kconfig  |   2 +-
 arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
 board/schneider/hmibsc/MAINTAINERS|   6 +
 board/schneider/hmibsc/hmibsc.env |  40 ++
 configs/hmibsc_defconfig  |  87 
 doc/board/index.rst   |   1 +
 doc/board/schneider/hmibsc.rst|  45 ++
 doc/board/schneider/index.rst |   9 +
 drivers/clk/qcom/clock-apq8016.c  |  38 +-
 drivers/pinctrl/qcom/pinctrl-apq8016.c|   2 +
 drivers/pinctrl/qcom/pinctrl-qcom.c   |  25 +-
 drivers/serial/serial_msm.c   |  24 +-
 include/configs/hmibsc.h  |  16 +
 13 files changed, 760 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts
 create mode 100644 board/schneider/hmibsc/MAINTAINERS
 create mode 100644 board/schneider/hmibsc/hmibsc.env
 create mode 100644 configs/hmibsc_defconfig
 create mode 100644 doc/board/schneider/hmibsc.rst
 create mode 100644 doc/board/schneider/index.rst
 create mode 100644 include/configs/hmibsc.h

-- 
2.34.1



Re: [PATCH 1/7] mmc: msm_sdhci: correct vendor_spec_cap0 register for v5

2024-04-12 Thread Sumit Garg
On Fri, 12 Apr 2024 at 14:06, Neil Armstrong  wrote:
>
> On 11/04/2024 15:59, Sumit Garg wrote:
> > On Tue, 9 Apr 2024 at 23:33, Caleb Connolly  
> > wrote:
> >>
> >> The V4 and V5 controllers have quite varied register layouts. Inherit
> >> the register offsets and naming from the Linux driver. More version
> >> specific offsets can be inherited from Linux as needed.
> >>
> >> Fixes: 364c22a ("mmc: msm_sdhci: Add SDCC version 5.0.0 support")
> >> Signed-off-by: Caleb Connolly 
> >> ---
> >>   drivers/mmc/msm_sdhci.c | 11 +++
> >>   1 file changed, 7 insertions(+), 4 deletions(-)
> >>
> >
> > This patch broke booting on the HMIBSC board, have you tested it on
> > db410c? It's very likely that this has caused regression there too.
> >
> > Error observed:
> >
> > sdhci_send_command: Timeout for status update:  0001
>
> Indeed swapping the core_vendor_spec_capabilities0 between msm_sdhc_v5_var & 
> msm_sdhc_mci_var
> fixes this and I'm now able to enable SDCard on the SM8550-HDK

Yeah this fixed the problem for me too. I am unsure how it worked for
Caleb on db845c.

Caleb,

Can you fix up this patch which is already in your tree already?

-Sumit

>
> Neil
>
> >
> > -Sumit
> >
> >> diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
> >> index 059cb3da77c5..f23d425144ef 100644
> >> --- a/drivers/mmc/msm_sdhci.c
> >> +++ b/drivers/mmc/msm_sdhci.c
> >> @@ -32,11 +32,8 @@
> >>   #define SDCC_MCI_STATUS2 0x6C
> >>   #define SDCC_MCI_STATUS2_MCI_ACT 0x1
> >>   #define SDCC_MCI_HC_MODE 0x78
> >>
> >> -/* Non standard (?) SDHCI register */
> >> -#define SDHCI_VENDOR_SPEC_CAPABILITIES0  0x11c
> >> -
> >>   struct msm_sdhc_plat {
> >>  struct mmc_config cfg;
> >>  struct mmc mmc;
> >>   };
> >> @@ -48,8 +45,10 @@ struct msm_sdhc {
> >>   };
> >>
> >>   struct msm_sdhc_variant_info {
> >>  bool mci_removed;
> >> +
> >> +   u32 core_vendor_spec_capabilities0;
> >>   };
> >>
> >>   DECLARE_GLOBAL_DATA_PTR;
> >>
> >> @@ -180,9 +179,9 @@ static int msm_sdc_probe(struct udevice *dev)
> >>   */
> >>  if (core_major >= 1 && core_minor != 0x11 && core_minor != 0x12) {
> >>  caps = readl(host->ioaddr + SDHCI_CAPABILITIES);
> >>  caps |= SDHCI_CAN_VDD_300 | SDHCI_CAN_DO_8BIT;
> >> -   writel(caps, host->ioaddr + 
> >> SDHCI_VENDOR_SPEC_CAPABILITIES0);
> >> +   writel(caps, host->ioaddr + 
> >> var_info->core_vendor_spec_capabilities0);
> >>  }
> >>
> >>  ret = mmc_of_parse(dev, >cfg);
> >>  if (ret)
> >> @@ -243,12 +242,16 @@ static int msm_sdc_bind(struct udevice *dev)
> >>   }
> >>
> >>   static const struct msm_sdhc_variant_info msm_sdhc_mci_var = {
> >>  .mci_removed = false,
> >> +
> >> +   .core_vendor_spec_capabilities0 = 0x21c,
> >>   };
> >>
> >>   static const struct msm_sdhc_variant_info msm_sdhc_v5_var = {
> >>  .mci_removed = true,
> >> +
> >> +   .core_vendor_spec_capabilities0 = 0x11c,
> >>   };
> >>
> >>   static const struct udevice_id msm_mmc_ids[] = {
> >>  { .compatible = "qcom,sdhci-msm-v4", .data = 
> >> (ulong)_sdhc_mci_var },
> >>
> >> --
> >> 2.44.0
> >>
>


Re: [PATCH 1/7] mmc: msm_sdhci: correct vendor_spec_cap0 register for v5

2024-04-11 Thread Sumit Garg
On Tue, 9 Apr 2024 at 23:33, Caleb Connolly  wrote:
>
> The V4 and V5 controllers have quite varied register layouts. Inherit
> the register offsets and naming from the Linux driver. More version
> specific offsets can be inherited from Linux as needed.
>
> Fixes: 364c22a ("mmc: msm_sdhci: Add SDCC version 5.0.0 support")
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/mmc/msm_sdhci.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>

This patch broke booting on the HMIBSC board, have you tested it on
db410c? It's very likely that this has caused regression there too.

Error observed:

sdhci_send_command: Timeout for status update:  0001

-Sumit

> diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
> index 059cb3da77c5..f23d425144ef 100644
> --- a/drivers/mmc/msm_sdhci.c
> +++ b/drivers/mmc/msm_sdhci.c
> @@ -32,11 +32,8 @@
>  #define SDCC_MCI_STATUS2 0x6C
>  #define SDCC_MCI_STATUS2_MCI_ACT 0x1
>  #define SDCC_MCI_HC_MODE 0x78
>
> -/* Non standard (?) SDHCI register */
> -#define SDHCI_VENDOR_SPEC_CAPABILITIES0  0x11c
> -
>  struct msm_sdhc_plat {
> struct mmc_config cfg;
> struct mmc mmc;
>  };
> @@ -48,8 +45,10 @@ struct msm_sdhc {
>  };
>
>  struct msm_sdhc_variant_info {
> bool mci_removed;
> +
> +   u32 core_vendor_spec_capabilities0;
>  };
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -180,9 +179,9 @@ static int msm_sdc_probe(struct udevice *dev)
>  */
> if (core_major >= 1 && core_minor != 0x11 && core_minor != 0x12) {
> caps = readl(host->ioaddr + SDHCI_CAPABILITIES);
> caps |= SDHCI_CAN_VDD_300 | SDHCI_CAN_DO_8BIT;
> -   writel(caps, host->ioaddr + SDHCI_VENDOR_SPEC_CAPABILITIES0);
> +   writel(caps, host->ioaddr + 
> var_info->core_vendor_spec_capabilities0);
> }
>
> ret = mmc_of_parse(dev, >cfg);
> if (ret)
> @@ -243,12 +242,16 @@ static int msm_sdc_bind(struct udevice *dev)
>  }
>
>  static const struct msm_sdhc_variant_info msm_sdhc_mci_var = {
> .mci_removed = false,
> +
> +   .core_vendor_spec_capabilities0 = 0x21c,
>  };
>
>  static const struct msm_sdhc_variant_info msm_sdhc_v5_var = {
> .mci_removed = true,
> +
> +   .core_vendor_spec_capabilities0 = 0x11c,
>  };
>
>  static const struct udevice_id msm_mmc_ids[] = {
> { .compatible = "qcom,sdhci-msm-v4", .data = (ulong)_sdhc_mci_var 
> },
>
> --
> 2.44.0
>


[PATCH v2] mach-snapdragon: Allow other board vendors apart from Qcom

2024-04-11 Thread Sumit Garg
Qcom SoCs derived boards can come from various OEMs/ODMs and not just
Qcom itself. So allow CONFIG_SYS_VENDOR to be set correctly
corressponding to the actual board vendor.

Suggested-by: Stephan Gerhold 
Reviewed-by: Caleb Connolly 
Signed-off-by: Sumit Garg 
---

Changes in v2:
- Retained default vendor being "qualcomm".
- Collected review tag.

 arch/arm/mach-snapdragon/Kconfig | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig
index 96e44e2c549..536960b83c3 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -4,7 +4,12 @@ config SYS_SOC
default "snapdragon"
 
 config SYS_VENDOR
+   string "Snapdragon board vendor"
default "qualcomm"
+   help
+ Allows to specify vendor for the Snapdragon SoCs based boards.
+ Based on this option board//
+ will be used as the custom board directory.
 
 config SYS_MALLOC_F_LEN
default 0x2000
@@ -19,12 +24,11 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE
default 0x8000
 
 config SYS_BOARD
-   string "Qualcomm custom board"
+   string "Snapdragon SoCs based board"
help
- The Dragonboard 410c and 820c have additional board init
- code that isn't shared with other Qualcomm boards.
- Based on this option board/qualcomm/ will
- be used.
+ Allows to specify the Snapdragon SoCs based board name.
+ Based on this option board//
+ will be used as the custom board directory.
 
 config SYS_CONFIG_NAME
string "Board configuration name"
-- 
2.34.1



Re: [PATCH v2 0/4] qcom: pinctrl drivers for qcm2290/sm6115/sm8250

2024-04-11 Thread Sumit Garg
On Wed, 10 Apr 2024 at 23:23, Caleb Connolly  wrote:
>
> Introduce pinctrl drivers for three new SoCs and enable them.
>
> Signed-off-by: Caleb Connolly 
> ---
> Changes in v2:
> - Fix a few formatting issues
> - Link to v1: 
> https://lore.kernel.org/r/20240408-b4-qcom-rbx-soc-v1-0-900db37b8...@linaro.org
>
> ---
> Caleb Connolly (4):
>   pinctrl: qcom: add qcm2290 pinctrl driver
>   pinctrl: qcom: add sm6115 pinctrl driver
>   pinctrl: qcom: add sm8250 pinctrl driver
>   qcom_defconfig: enable pinctrl for new qcm2290/sm6115/sm8250
>

Acked-by: Sumit Garg 

-Sumit

>  configs/qcom_defconfig |   3 +
>  drivers/pinctrl/qcom/Kconfig   |  21 
>  drivers/pinctrl/qcom/Makefile  |   3 +
>  drivers/pinctrl/qcom/pinctrl-qcm2290.c |  70 
>  drivers/pinctrl/qcom/pinctrl-sm6115.c  | 200 
> +
>  drivers/pinctrl/qcom/pinctrl-sm8250.c  |  99 
>  6 files changed, 396 insertions(+)
> ---
> change-id: 20240408-b4-qcom-rbx-soc-44ee99c8b799
> base-commit: 4ba549b0a4e67c563785ab144edf47e108b34822
>
> // Caleb (they/them)
>


Re: [PATCH v2 0/2] phy: qcom: add support for the Qualcomm Synopsys eUSB2 PHY

2024-04-11 Thread Sumit Garg
On Wed, 10 Apr 2024 at 21:31, Neil Armstrong  wrote:
>
> Add support for the new Qualcomm Synopsys eUSB2 PHY found in the
> SM8550 and SM8650 SoCs.
>
> Finally enable the driver in the Qualcomm defconfig.
>
> Signed-off-by: Neil Armstrong 
> ---
> Changes in v2:
> - fixed driver build failure due to missin }
> - Link to v1: 
> https://lore.kernel.org/r/20240405-topic-sm8x50-usb-phy-v1-0-8a8604bf8...@linaro.org
>
> ---
> Neil Armstrong (2):
>   phy: qcom: add Synopsys eUSB2 PHY driver
>   qcom_defconfig: enable the Qualcomm Synopsys eUSB2 PHY driver
>

Acked-by: Sumit Garg 

-Sumit

>  configs/qcom_defconfig |   1 +
>  drivers/phy/qcom/Kconfig   |   8 +
>  drivers/phy/qcom/Makefile  |   1 +
>  drivers/phy/qcom/phy-qcom-snps-eusb2.c | 366 
> +
>  4 files changed, 376 insertions(+)
> ---
> base-commit: f0e6aba1218bca578605697eed8aa94582bf57bb
> change-id: 20240404-topic-sm8x50-usb-phy-d09a98f72d1b
>
> Best regards,
> --
> Neil Armstrong 
>


[PATCH] mach-snapdragon: Allow other board vendors apart from Qcom

2024-04-11 Thread Sumit Garg
Qcom SoCs derived boards can come from various OEMs/ODMs and not just
Qcom itself. So allow CONFIG_SYS_VENDOR to be set correctly
corressponding to the actual board vendor.

Suggested-by: Stephan Gerhold 
Signed-off-by: Sumit Garg 
---
 arch/arm/mach-snapdragon/Kconfig  | 15 +--
 configs/dragonboard410c_defconfig |  1 +
 configs/dragonboard820c_defconfig |  1 +
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-snapdragon/Kconfig b/arch/arm/mach-snapdragon/Kconfig
index 96e44e2c549..4615a140d0d 100644
--- a/arch/arm/mach-snapdragon/Kconfig
+++ b/arch/arm/mach-snapdragon/Kconfig
@@ -4,7 +4,11 @@ config SYS_SOC
default "snapdragon"
 
 config SYS_VENDOR
-   default "qualcomm"
+   string "Snapdragon board vendor"
+   help
+ Allows to specify vendor for the Snapdragon SoCs based boards.
+ Based on this option board//
+ will be used as the custom board directory.
 
 config SYS_MALLOC_F_LEN
default 0x2000
@@ -19,12 +23,11 @@ config LNX_KRNL_IMG_TEXT_OFFSET_BASE
default 0x8000
 
 config SYS_BOARD
-   string "Qualcomm custom board"
+   string "Snapdragon SoCs based board"
help
- The Dragonboard 410c and 820c have additional board init
- code that isn't shared with other Qualcomm boards.
- Based on this option board/qualcomm/ will
- be used.
+ Allows to specify the Snapdragon SoCs based board name.
+ Based on this option board//
+ will be used as the custom board directory.
 
 config SYS_CONFIG_NAME
string "Board configuration name"
diff --git a/configs/dragonboard410c_defconfig 
b/configs/dragonboard410c_defconfig
index 260a8349d3b..3b6f50307a3 100644
--- a/configs/dragonboard410c_defconfig
+++ b/configs/dragonboard410c_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_SYS_VENDOR="qualcomm"
 CONFIG_SYS_BOARD="dragonboard410c"
 CONFIG_COUNTER_FREQUENCY=1900
 CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
diff --git a/configs/dragonboard820c_defconfig 
b/configs/dragonboard820c_defconfig
index ebc80eb2a46..a795497ef5d 100644
--- a/configs/dragonboard820c_defconfig
+++ b/configs/dragonboard820c_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_SYS_VENDOR="qualcomm"
 CONFIG_SYS_BOARD="dragonboard820c"
 CONFIG_COUNTER_FREQUENCY=1900
 CONFIG_ARCH_SNAPDRAGON=y
-- 
2.34.1



Re: [PATCH 3/4] clk/qcom: add driver for sm8250 GCC

2024-04-10 Thread Sumit Garg
Hi Caleb,

On Mon, 8 Apr 2024 at 18:37, Caleb Connolly  wrote:
>
> Add a clock driver for the SM8250 SoC. This driver can enable necessary
> clocks for UART, UFS, USB, and MMC.
>
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/clk/qcom/Kconfig|   8 ++
>  drivers/clk/qcom/Makefile   |   1 +
>  drivers/clk/qcom/clock-qcom.h   |   1 +
>  drivers/clk/qcom/clock-sm8250.c | 282 
> 
>  4 files changed, 292 insertions(+)
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 6afa62e19879..d4bd8c7e6ba6 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -62,7 +62,15 @@ config CLK_QCOM_SM6115
>   Say Y here to enable support for the Global Clock Controller
>   on the Snapdragon SM6115 SoC. This driver supports the clocks
>   and resets exposed by the GCC hardware block.
>
> +config CLK_QCOM_SM8250
> +   bool "Qualcomm SM8250 GCC"
> +   select CLK_QCOM
> +   help
> + Say Y here to enable support for the Global Clock Controller
> + on the Snapdragon SM8250 SoC. This driver supports the clocks
> + and resets exposed by the GCC hardware block.
> +
>  endmenu
>
>  endif
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index d38c5a9fb849..f7fc8b9a70f5 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -9,4 +9,5 @@ obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
>  obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
>  obj-$(CONFIG_CLK_QCOM_QCM2290) += clock-qcm2290.o
>  obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
>  obj-$(CONFIG_CLK_QCOM_SM6115) += clock-sm6115.o
> +obj-$(CONFIG_CLK_QCOM_SM8250) += clock-sm8250.o
> diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
> index ec524157df2b..cc170d8e3f9e 100644
> --- a/drivers/clk/qcom/clock-qcom.h
> +++ b/drivers/clk/qcom/clock-qcom.h
> @@ -9,8 +9,9 @@
>
>  #define CFG_CLK_SRC_CXO   (0 << 8)
>  #define CFG_CLK_SRC_GPLL0 (1 << 8)
>  #define CFG_CLK_SRC_GPLL0_AUX2 (2 << 8)
> +#define CFG_CLK_SRC_GPLL9 (2 << 8)
>  #define CFG_CLK_SRC_GPLL6 (4 << 8)
>  #define CFG_CLK_SRC_GPLL7 (3 << 8)
>  #define CFG_CLK_SRC_GPLL0_EVEN (6 << 8)
>  #define CFG_CLK_SRC_MASK  (7 << 8)
> diff --git a/drivers/clk/qcom/clock-sm8250.c b/drivers/clk/qcom/clock-sm8250.c
> new file mode 100644
> index ..af10fc116219
> --- /dev/null
> +++ b/drivers/clk/qcom/clock-sm8250.c
> @@ -0,0 +1,282 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Clock drivers for Qualcomm sm8250
> + *
> + * (C) Copyright 2024 Linaro Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clock-qcom.h"
> +
> +#define GCC_SE12_UART_RCG_REG 0x184D0
> +#define GCC_SDCC2_APPS_CLK_SRC_REG 0x1400c
> +
> +#define APCS_GPLL0_ENA_VOTE 0x79000
> +#define APCS_GPLL9_STATUS 0x1c000
> +#define APCS_GPLLX_ENA_REG 0x52018
> +
> +#define USB30_PRIM_MASTER_CLK_CMD_RCGR 0xf020
> +#define USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR 0xf038
> +#define USB3_PRIM_PHY_AUX_CMD_RCGR 0xf064
> +
> +static const struct freq_tbl ftbl_gcc_qupv3_wrap1_s4_clk_src[] = {
> +   F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
> +   F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
> +   F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> +   F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
> +   F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
> +   F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
> +   F(5000, CFG_CLK_SRC_GPLL0_EVEN, 6, 0, 0),
> +   F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
> +   F(7500, CFG_CLK_SRC_GPLL0_EVEN, 4, 0, 0),
> +   F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
> +   F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
> +   F(1, CFG_CLK_SRC_GPLL0, 6, 0, 0),
> +   {}
> +};
> +
> +static const struct freq_tbl ftbl_gcc_sdcc2_apps_clk_src[] = {
> +   F(40, CFG_CLK_SRC_CXO, 12, 1, 4),
> +   F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> +   F(2500, CFG_CLK_SRC_GPLL0_EVEN, 12, 0, 0),
> +   F(5000, CFG_CLK_SRC_GPLL0_EVEN, 6, 0, 0),
> +   F(1, CFG_CLK_SRC_GPLL0, 6, 0, 0),
> +   F(20200, CFG_CLK_SRC_GPLL9, 4, 0, 0),
> +   {}
> +};
> +
> +static struct pll_vote_clk gpll9_vote_clk = {
> +   .status = APCS_GPLL9_STATUS,
> +   .status_bit = BIT(31),
> +   .ena_vote = APCS_GPLLX_ENA_REG,
> +   .vote_bit = BIT(9),
> +};
> +
> +static ulong sm8250_set_rate(struct clk *clk, ulong rate)
> +{
> +   struct msm_clk_priv *priv = dev_get_priv(clk->dev);
> +   const struct freq_tbl *freq;
> +
> +   if (clk->id < priv->data->num_clks)
> +   debug("%s: %s, requested rate=%ld\n", __func__,
> + priv->data->clks[clk->id].name, rate);
> +
> +   switch (clk->id) {
> +   case GCC_QUPV3_WRAP1_S4_CLK: /*UART2*/
> +   freq = qcom_find_freq(ftbl_gcc_qupv3_wrap1_s4_clk_src, 

Re: [PATCH] MAINTAINERS: add Qualcomm mailing list

2024-04-10 Thread Sumit Garg
On Tue, 9 Apr 2024 at 20:32, Caleb Connolly  wrote:
>
> Add the newly created u-boot-qcom mailing list to keep track of Qualcomm
> patches.
>
> Additionally, link to the U-Boot Snapdragon custodian tree.
>
> Signed-off-by: Caleb Connolly 
> ---
>
> Cc: Neil Armstrong 
> Cc: Sumit Garg 
> Cc: u-boot@lists.denx.de
> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0462ade4ac60..c0d2b5138fca 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -602,9 +602,11 @@ F: arch/arm/dts/am335x-sancloud*
>  ARM SNAPDRAGON
>  M: Caleb Connolly 
>  M: Neil Armstrong 
>  R: Sumit Garg 
> +L: u-boot-q...@groups.io
>  S: Maintained
> +T: git https://source.denx.de/u-boot/custodians/u-boot-snapdragon.git
>  F: arch/arm/dts/msm8*.dtsi
>  F: arch/arm/dts/pm8???.dtsi
>  F: arch/arm/dts/pms405.dtsi
>  F: arch/arm/dts/sdm845.dtsi
> --
> 2.44.0
>


Re: [PATCH 7/7] dts: sdm845-db845c-u-boot: adjust MMC clocks

2024-04-10 Thread Sumit Garg
Hi Caleb,

On Tue, 9 Apr 2024 at 23:33, Caleb Connolly  wrote:
>
> Remove the reference to the xo clock which is on the unsupported rpmhcc
> clock controller. It isn't needed for MMC functionality.

Can it rather be handled via a NOP clock driver for rpmhcc? I suppose
this kind of DT modifications would push us away from upstream DT
compatibility.

-Sumit

>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/dts/sdm845-db845c-u-boot.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/dts/sdm845-db845c-u-boot.dtsi 
> b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
> index 906f9faa5451..9e4533e603c5 100644
> --- a/arch/arm/dts/sdm845-db845c-u-boot.dtsi
> +++ b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
> @@ -6,4 +6,11 @@
>   */
>  _3p3v_dual {
> regulator-always-on;
>  };
> +
> +_2 {
> +   /* Remove the unsupported rpmhcc xo clock reference */
> +   clocks = < GCC_SDCC2_AHB_CLK>,
> +< GCC_SDCC2_APPS_CLK>;
> +   clock-names = "iface", "core";
> +};
>
> --
> 2.44.0
>


Re: [PATCH 3/3] qcom_defconfig: enable SM8550 & SM8650 pinctrl driver

2024-04-10 Thread Sumit Garg
On Fri, 5 Apr 2024 at 13:45, Neil Armstrong  wrote:
>
> Enable the SM8550 & SM8650 pinctrl drivers for Qualcomm defconfig.
>
> Signed-off-by: Neil Armstrong 
> ---
>  configs/qcom_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> index 222db6448ab..a92b6ef7911 100644
> --- a/configs/qcom_defconfig
> +++ b/configs/qcom_defconfig
> @@ -43,6 +43,8 @@ CONFIG_PHY=y
>  CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_QCOM_QCS404=y
>  CONFIG_PINCTRL_QCOM_SDM845=y
> +CONFIG_PINCTRL_QCOM_SM8550=y
> +CONFIG_PINCTRL_QCOM_SM8650=y
>  CONFIG_DM_PMIC=y
>  CONFIG_PMIC_QCOM=y
>  CONFIG_SCSI=y
>
> --
> 2.34.1
>


Re: [PATCH 2/3] pinctrl: qcom: Add SM8650 pinctrl driver

2024-04-10 Thread Sumit Garg
On Fri, 5 Apr 2024 at 13:45, Neil Armstrong  wrote:
>
> Add pinctrl driver for the TLMM block found in the SM8650 SoC.
>
> This driver only handles the gpio and qup2_se7 pinmux, and makes sure
> the pinconf applies on SDC2 pins.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/pinctrl/qcom/Kconfig  |  7 
>  drivers/pinctrl/qcom/Makefile |  1 +
>  drivers/pinctrl/qcom/pinctrl-sm8650.c | 75 
> +++
>  3 files changed, 83 insertions(+)
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
> index f760bbcdd52..e0196a83e60 100644
> --- a/drivers/pinctrl/qcom/Kconfig
> +++ b/drivers/pinctrl/qcom/Kconfig
> @@ -48,6 +48,13 @@ config PINCTRL_QCOM_SM8550
>   Say Y here to enable support for pinctrl on the Snapdragon SM8550 
> SoC,
>   as well as the associated GPIO driver.
>
> +config PINCTRL_QCOM_SM8650
> +   bool "Qualcomm SM8650 GCC"
> +   select PINCTRL_QCOM
> +   help
> + Say Y here to enable support for pinctrl on the Snapdragon SM8650 
> SoC,
> + as well as the associated GPIO driver.
> +
>  endmenu
>
>  endif
> diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
> index 970902e28c8..d83e89ef4f0 100644
> --- a/drivers/pinctrl/qcom/Makefile
> +++ b/drivers/pinctrl/qcom/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_PINCTRL_QCOM_APQ8096) += pinctrl-apq8096.o
>  obj-$(CONFIG_PINCTRL_QCOM_QCS404) += pinctrl-qcs404.o
>  obj-$(CONFIG_PINCTRL_QCOM_SDM845) += pinctrl-sdm845.o
>  obj-$(CONFIG_PINCTRL_QCOM_SM8550) += pinctrl-sm8550.o
> +obj-$(CONFIG_PINCTRL_QCOM_SM8650) += pinctrl-sm8650.o
> diff --git a/drivers/pinctrl/qcom/pinctrl-sm8650.c 
> b/drivers/pinctrl/qcom/pinctrl-sm8650.c
> new file mode 100644
> index 000..932132fa4a6
> --- /dev/null
> +++ b/drivers/pinctrl/qcom/pinctrl-sm8650.c
> @@ -0,0 +1,75 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm sm8650 pinctrl
> + *
> + * (C) Copyright 2024 Linaro Ltd.
> + *
> + */
> +
> +#include 
> +#include 
> +
> +#include "pinctrl-qcom.h"
> +
> +#define MAX_PIN_NAME_LEN 32
> +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> +
> +static const struct pinctrl_function msm_pinctrl_functions[] = {
> +   {"qup2_se7", 1},
> +   {"gpio", 0},
> +};
> +
> +static const char *sm8650_get_function_name(struct udevice *dev,
> +unsigned int selector)
> +{
> +   return msm_pinctrl_functions[selector].name;
> +}
> +
> +static const char *sm8650_get_pin_name(struct udevice *dev,
> +   unsigned int selector)
> +{
> +   static const char *special_pins_names[] = {
> +   "ufs_reset",
> +   "sdc2_clk",
> +   "sdc2_cmd",
> +   "sdc2_data",
> +   };
> +
> +   if (selector >= 210 && selector <= 213)
> +   snprintf(pin_name, MAX_PIN_NAME_LEN, 
> special_pins_names[selector - 210]);
> +   else
> +   snprintf(pin_name, MAX_PIN_NAME_LEN, "gpio%u", selector);
> +
> +   return pin_name;
> +}
> +
> +static unsigned int sm8650_get_function_mux(__maybe_unused unsigned int pin,
> +   unsigned int selector)
> +{
> +   return msm_pinctrl_functions[selector].val;
> +}
> +
> +static struct msm_pinctrl_data sm8650_data = {
> +   .pin_data = {
> +   .pin_count = 214,
> +   .special_pins_start = 210,
> +   },
> +   .functions_count = ARRAY_SIZE(msm_pinctrl_functions),
> +   .get_function_name = sm8650_get_function_name,
> +   .get_function_mux = sm8650_get_function_mux,
> +   .get_pin_name = sm8650_get_pin_name,
> +};
> +
> +static const struct udevice_id msm_pinctrl_ids[] = {
> +   { .compatible = "qcom,sm8650-tlmm", .data = (ulong)_data },
> +   { /* Sentinel */ }
> +};
> +
> +U_BOOT_DRIVER(pinctrl_sm8650) = {
> +   .name   = "pinctrl_sm8650",
> +   .id = UCLASS_NOP,
> +   .of_match   = msm_pinctrl_ids,
> +   .ops= _pinctrl_ops,
> +   .bind   = msm_pinctrl_bind,
> +};
> +
>
> --
> 2.34.1
>


Re: [PATCH 1/3] pinctrl: qcom: Add SM8550 pinctrl driver

2024-04-10 Thread Sumit Garg
On Fri, 5 Apr 2024 at 13:45, Neil Armstrong  wrote:
>
> Add pinctrl driver for the TLMM block found in the SM8550 SoC.
>
> This driver only handles the gpio and qup1_se7 pinmux, and makes sure
> the pinconf applies on SDC2 pins.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/pinctrl/qcom/Kconfig  |  7 
>  drivers/pinctrl/qcom/Makefile |  1 +
>  drivers/pinctrl/qcom/pinctrl-sm8550.c | 75 
> +++
>  3 files changed, 83 insertions(+)
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
> index 2fe63981478..f760bbcdd52 100644
> --- a/drivers/pinctrl/qcom/Kconfig
> +++ b/drivers/pinctrl/qcom/Kconfig
> @@ -41,6 +41,13 @@ config PINCTRL_QCOM_SDM845
>   Say Y here to enable support for pinctrl on the Snapdragon 845 SoC,
>   as well as the associated GPIO driver.
>
> +config PINCTRL_QCOM_SM8550
> +   bool "Qualcomm SM8550 GCC"
> +   select PINCTRL_QCOM
> +   help
> + Say Y here to enable support for pinctrl on the Snapdragon SM8550 
> SoC,
> + as well as the associated GPIO driver.
> +
>  endmenu
>
>  endif
> diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
> index 6d9aca6d7b7..970902e28c8 100644
> --- a/drivers/pinctrl/qcom/Makefile
> +++ b/drivers/pinctrl/qcom/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_PINCTRL_QCOM_IPQ4019) += pinctrl-ipq4019.o
>  obj-$(CONFIG_PINCTRL_QCOM_APQ8096) += pinctrl-apq8096.o
>  obj-$(CONFIG_PINCTRL_QCOM_QCS404) += pinctrl-qcs404.o
>  obj-$(CONFIG_PINCTRL_QCOM_SDM845) += pinctrl-sdm845.o
> +obj-$(CONFIG_PINCTRL_QCOM_SM8550) += pinctrl-sm8550.o
> diff --git a/drivers/pinctrl/qcom/pinctrl-sm8550.c 
> b/drivers/pinctrl/qcom/pinctrl-sm8550.c
> new file mode 100644
> index 000..d9a8a652111
> --- /dev/null
> +++ b/drivers/pinctrl/qcom/pinctrl-sm8550.c
> @@ -0,0 +1,75 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm sm8550 pinctrl
> + *
> + * (C) Copyright 2024 Linaro Ltd.
> + *
> + */
> +
> +#include 
> +#include 
> +
> +#include "pinctrl-qcom.h"
> +
> +#define MAX_PIN_NAME_LEN 32
> +static char pin_name[MAX_PIN_NAME_LEN] __section(".data");
> +
> +static const struct pinctrl_function msm_pinctrl_functions[] = {
> +   {"qup1_se7", 1},
> +   {"gpio", 0},
> +};
> +
> +static const char *sm8550_get_function_name(struct udevice *dev,
> +unsigned int selector)
> +{
> +   return msm_pinctrl_functions[selector].name;
> +}
> +
> +static const char *sm8550_get_pin_name(struct udevice *dev,
> +   unsigned int selector)
> +{
> +   static const char *special_pins_names[] = {
> +   "ufs_reset",
> +   "sdc2_clk",
> +   "sdc2_cmd",
> +   "sdc2_data",
> +   };
> +
> +   if (selector >= 210 && selector <= 213)
> +   snprintf(pin_name, MAX_PIN_NAME_LEN, 
> special_pins_names[selector - 210]);
> +   else
> +   snprintf(pin_name, MAX_PIN_NAME_LEN, "gpio%u", selector);
> +
> +   return pin_name;
> +}
> +
> +static unsigned int sm8550_get_function_mux(__maybe_unused unsigned int pin,
> +   unsigned int selector)
> +{
> +   return msm_pinctrl_functions[selector].val;
> +}
> +
> +static struct msm_pinctrl_data sm8550_data = {
> +   .pin_data = {
> +   .pin_count = 214,
> +   .special_pins_start = 210,
> +   },
> +   .functions_count = ARRAY_SIZE(msm_pinctrl_functions),
> +   .get_function_name = sm8550_get_function_name,
> +   .get_function_mux = sm8550_get_function_mux,
> +   .get_pin_name = sm8550_get_pin_name,
> +};
> +
> +static const struct udevice_id msm_pinctrl_ids[] = {
> +   { .compatible = "qcom,sm8550-tlmm", .data = (ulong)_data },
> +   { /* Sentinel */ }
> +};
> +
> +U_BOOT_DRIVER(pinctrl_sm8550) = {
> +   .name   = "pinctrl_sm8550",
> +   .id = UCLASS_NOP,
> +   .of_match   = msm_pinctrl_ids,
> +   .ops= _pinctrl_ops,
> +   .bind   = msm_pinctrl_bind,
> +};
> +
>
> --
> 2.34.1
>


Re: [PATCH 1/3] clk: qcom: Add SM8550 clock driver

2024-04-10 Thread Sumit Garg
On Wed, 10 Apr 2024 at 15:00,  wrote:
>
> On 10/04/2024 11:27, Sumit Garg wrote:
> > On Wed, 10 Apr 2024 at 14:46, Neil Armstrong  
> > wrote:
> >>
> >> On 10/04/2024 11:13, Sumit Garg wrote:
> >>> Hi Neil,
> >>>
> >>> On Thu, 4 Apr 2024 at 22:16, Neil Armstrong  
> >>> wrote:
> >>>>
> >>>> Add the GCC and TCSRCC clock driver for the SM8550 SoC.
> >>>>
> >>>> The GCC driver uses the clk-qcom infrastructure to support GDSCs,
> >>>> Resets and gates. While the TCSRCC is a simpler clock driver which
> >>>> only supports gates.
> >>>>
> >>>> The GCC enable and set_rate callbacks contains some tweaks to
> >>>> setup clocks for Debug UART, SDCard controller and USB.
> >>>
> >>> Okay so these are the peripherals you intend to support to begin with.
> >>>
> >>>>
> >>>> The TCSRCC gates returns the XO frequency, which is used by the
> >>>> Synopsys eUSB2 driver to determine the PHY configuration.
> >>>>
> >>>> Signed-off-by: Neil Armstrong 
> >>>> ---
> >>>>drivers/clk/qcom/Kconfig|   8 +
> >>>>drivers/clk/qcom/Makefile   |   1 +
> >>>>drivers/clk/qcom/clock-sm8550.c | 335 
> >>>> 
> >>>>3 files changed, 344 insertions(+)
> >>>>
> >>>> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> >>>> index 8dae635ac2c..c908a3d19c9 100644
> >>>> --- a/drivers/clk/qcom/Kconfig
> >>>> +++ b/drivers/clk/qcom/Kconfig
> >>>> @@ -47,6 +47,14 @@ config CLK_QCOM_SDM845
> >>>> on the Snapdragon 845 SoC. This driver supports the clocks
> >>>> and resets exposed by the GCC hardware block.
> >>>>
> >>>> +config CLK_QCOM_SM8550
> >>>> +   bool "Qualcomm SM8550 GCC"
> >>>> +   select CLK_QCOM
> >>>> +   help
> >>>> + Say Y here to enable support for the Global Clock Controller
> >>>> + on the Snapdragon SM8550 SoC. This driver supports the clocks
> >>>> + and resets exposed by the GCC hardware block.
> >>>> +
> >>>>endmenu
> >>>>
> >>>>endif
> >>>> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> >>>> index cb179fdac58..d9ac5719f49 100644
> >>>> --- a/drivers/clk/qcom/Makefile
> >>>> +++ b/drivers/clk/qcom/Makefile
> >>>> @@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8016) += clock-apq8016.o
> >>>>obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
> >>>>obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
> >>>>obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
> >>>> +obj-$(CONFIG_CLK_QCOM_SM8550) += clock-sm8550.o
> >>>> diff --git a/drivers/clk/qcom/clock-sm8550.c 
> >>>> b/drivers/clk/qcom/clock-sm8550.c
> >>>> new file mode 100644
> >>>> index 000..c0249925cc7
> >>>> --- /dev/null
> >>>> +++ b/drivers/clk/qcom/clock-sm8550.c
> >>>> @@ -0,0 +1,335 @@
> >>>> +// SPDX-License-Identifier: BSD-3-Clause
> >>>> +/*
> >>>> + * Clock drivers for Qualcomm sm8550
> >>>> + *
> >>>> + * (C) Copyright 2024 Linaro Ltd.
> >>>> + */
> >>>> +
> >>>> +#include 
> >>>> +#include 
> >>>> +#include 
> >>>> +#include 
> >>>> +#include 
> >>>> +#include 
> >>>> +#include 
> >>>> +#include 
> >>>> +#include 
> >>>> +
> >>>> +#include "clock-qcom.h"
> >>>> +
> >>>> +/* On-board TCXO, TOFIX get from DT */
> >>>> +#define TCXO_RATE  3840
> >>>> +
> >>>> +/* bi_tcxo_div2 divided after RPMh output */
> >>>> +#define TCXO_DIV2_RATE (TCXO_RATE / 2)
> >>>> +
> >>>> +static const struct freq_tbl ftbl_gcc_qupv3_wrap1_s2_clk_src[] = {
> >>>> +   F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
> >>>> +   F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
> >>>> +   F(1920, CFG

Re: [PATCH 1/3] clk: qcom: Add SM8550 clock driver

2024-04-10 Thread Sumit Garg
On Wed, 10 Apr 2024 at 14:46, Neil Armstrong  wrote:
>
> On 10/04/2024 11:13, Sumit Garg wrote:
> > Hi Neil,
> >
> > On Thu, 4 Apr 2024 at 22:16, Neil Armstrong  
> > wrote:
> >>
> >> Add the GCC and TCSRCC clock driver for the SM8550 SoC.
> >>
> >> The GCC driver uses the clk-qcom infrastructure to support GDSCs,
> >> Resets and gates. While the TCSRCC is a simpler clock driver which
> >> only supports gates.
> >>
> >> The GCC enable and set_rate callbacks contains some tweaks to
> >> setup clocks for Debug UART, SDCard controller and USB.
> >
> > Okay so these are the peripherals you intend to support to begin with.
> >
> >>
> >> The TCSRCC gates returns the XO frequency, which is used by the
> >> Synopsys eUSB2 driver to determine the PHY configuration.
> >>
> >> Signed-off-by: Neil Armstrong 
> >> ---
> >>   drivers/clk/qcom/Kconfig|   8 +
> >>   drivers/clk/qcom/Makefile   |   1 +
> >>   drivers/clk/qcom/clock-sm8550.c | 335 
> >> 
> >>   3 files changed, 344 insertions(+)
> >>
> >> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> >> index 8dae635ac2c..c908a3d19c9 100644
> >> --- a/drivers/clk/qcom/Kconfig
> >> +++ b/drivers/clk/qcom/Kconfig
> >> @@ -47,6 +47,14 @@ config CLK_QCOM_SDM845
> >>on the Snapdragon 845 SoC. This driver supports the clocks
> >>and resets exposed by the GCC hardware block.
> >>
> >> +config CLK_QCOM_SM8550
> >> +   bool "Qualcomm SM8550 GCC"
> >> +   select CLK_QCOM
> >> +   help
> >> + Say Y here to enable support for the Global Clock Controller
> >> + on the Snapdragon SM8550 SoC. This driver supports the clocks
> >> + and resets exposed by the GCC hardware block.
> >> +
> >>   endmenu
> >>
> >>   endif
> >> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> >> index cb179fdac58..d9ac5719f49 100644
> >> --- a/drivers/clk/qcom/Makefile
> >> +++ b/drivers/clk/qcom/Makefile
> >> @@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8016) += clock-apq8016.o
> >>   obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
> >>   obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
> >>   obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
> >> +obj-$(CONFIG_CLK_QCOM_SM8550) += clock-sm8550.o
> >> diff --git a/drivers/clk/qcom/clock-sm8550.c 
> >> b/drivers/clk/qcom/clock-sm8550.c
> >> new file mode 100644
> >> index 000..c0249925cc7
> >> --- /dev/null
> >> +++ b/drivers/clk/qcom/clock-sm8550.c
> >> @@ -0,0 +1,335 @@
> >> +// SPDX-License-Identifier: BSD-3-Clause
> >> +/*
> >> + * Clock drivers for Qualcomm sm8550
> >> + *
> >> + * (C) Copyright 2024 Linaro Ltd.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "clock-qcom.h"
> >> +
> >> +/* On-board TCXO, TOFIX get from DT */
> >> +#define TCXO_RATE  3840
> >> +
> >> +/* bi_tcxo_div2 divided after RPMh output */
> >> +#define TCXO_DIV2_RATE (TCXO_RATE / 2)
> >> +
> >> +static const struct freq_tbl ftbl_gcc_qupv3_wrap1_s2_clk_src[] = {
> >> +   F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
> >> +   F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
> >> +   F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> >> +   F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
> >> +   F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
> >> +   F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
> >> +   F(5120, CFG_CLK_SRC_GPLL0_EVEN, 1, 64, 375),
> >> +   F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
> >> +   F(7500, CFG_CLK_SRC_GPLL0_EVEN, 4, 0, 0),
> >> +   F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
> >> +   F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
> >> +   F(1, CFG_CLK_SRC_GPLL0, 6, 0, 0),
> >> +   { }
> >> +};
> >> +
> >> +static const struct freq_tbl ftbl_gcc_sdcc2_apps_clk_src[] = {
> >> +   F(40, CFG_CLK_SRC_CXO, 12, 1, 4),
> >> +

Re: [PATCH 2/3] clk: qcom: Add SM8650 clock driver

2024-04-10 Thread Sumit Garg
On Thu, 4 Apr 2024 at 22:16, Neil Armstrong  wrote:
>
> Add the GCC and TCSRCC clock driver for the SM8650 SoC.
>
> The GCC driver uses the clk-qcom infrastructure to support GDSCs,
> Resets and gates. While the TCSRCC is a simpler clock driver which
> only supports gates.
>
> The GCC enable and set_rate callbacks contains some tweaks to
> setup clocks for Debug UART, SDCard controller and USB.
>

Similar comments as on patch#1, we should drop the bits that we don't
intend to support as of now.

-Sumit

> The TCSRCC gates returns the XO frequency, which is used by the
> Synopsys eUSB2 driver to determine the PHY configuration.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/clk/qcom/Kconfig|   8 +
>  drivers/clk/qcom/Makefile   |   1 +
>  drivers/clk/qcom/clock-sm8650.c | 332 
> 
>  3 files changed, 341 insertions(+)
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index c908a3d19c9..a9216ea30d4 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -55,6 +55,14 @@ config CLK_QCOM_SM8550
>   on the Snapdragon SM8550 SoC. This driver supports the clocks
>   and resets exposed by the GCC hardware block.
>
> +config CLK_QCOM_SM8650
> +   bool "Qualcomm SM8650 GCC"
> +   select CLK_QCOM
> +   help
> + Say Y here to enable support for the Global Clock Controller
> + on the Snapdragon SM8650 SoC. This driver supports the clocks
> + and resets exposed by the GCC hardware block.
> +
>  endmenu
>
>  endif
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index d9ac5719f49..3ccb4ffae76 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
>  obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
>  obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
>  obj-$(CONFIG_CLK_QCOM_SM8550) += clock-sm8550.o
> +obj-$(CONFIG_CLK_QCOM_SM8650) += clock-sm8650.o
> diff --git a/drivers/clk/qcom/clock-sm8650.c b/drivers/clk/qcom/clock-sm8650.c
> new file mode 100644
> index 000..0ce83e9b243
> --- /dev/null
> +++ b/drivers/clk/qcom/clock-sm8650.c
> @@ -0,0 +1,332 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Clock drivers for Qualcomm sm8650
> + *
> + * (C) Copyright 2024 Linaro Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clock-qcom.h"
> +
> +/* On-board TCXO, TOFIX get from DT */
> +#define TCXO_RATE  3840
> +
> +/* bi_tcxo_div2 divided after RPMh output */
> +#define TCXO_DIV2_RATE (TCXO_RATE / 2)
> +
> +static const struct freq_tbl ftbl_gcc_qupv3_wrap1_s3_clk_src[] = {
> +   F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
> +   F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
> +   F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> +   F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
> +   F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
> +   F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
> +   F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
> +   F(7500, CFG_CLK_SRC_GPLL0_EVEN, 4, 0, 0),
> +   F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
> +   F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
> +   F(1, CFG_CLK_SRC_GPLL0, 6, 0, 0),
> +   { }
> +};
> +
> +static const struct freq_tbl ftbl_gcc_sdcc2_apps_clk_src[] = {
> +   F(40, CFG_CLK_SRC_CXO, 12, 1, 4),
> +   F(2500, CFG_CLK_SRC_GPLL0_EVEN, 12, 0, 0),
> +   F(1, CFG_CLK_SRC_GPLL0_EVEN, 3, 0, 0),
> +   /* TOFIX F(20200, CFG_CLK_SRC_GPLL9, 4, 0, 0), */
> +   { }
> +};
> +
> +static const struct freq_tbl ftbl_gcc_usb30_prim_master_clk_src[] = {
> +   F(6667, CFG_CLK_SRC_GPLL0_EVEN, 4.5, 0, 0),
> +   F(1, CFG_CLK_SRC_GPLL0, 4.5, 0, 0),
> +   F(2, CFG_CLK_SRC_GPLL0, 3, 0, 0),
> +   F(24000, CFG_CLK_SRC_GPLL0, 2.5, 0, 0),
> +   { }
> +};
> +
> +static ulong sm8650_set_rate(struct clk *clk, ulong rate)
> +{
> +   struct msm_clk_priv *priv = dev_get_priv(clk->dev);
> +   const struct freq_tbl *freq;
> +
> +   switch (clk->id) {
> +   case GCC_QUPV3_WRAP2_S7_CLK: /* UART15 */
> +   freq = qcom_find_freq(ftbl_gcc_qupv3_wrap1_s3_clk_src, rate);
> +   clk_rcg_set_rate_mnd(priv->base, 0x1e898,
> +freq->pre_div, freq->m, freq->n, 
> freq->src, 16);
> +   return freq->freq;
> +   case GCC_SDCC2_APPS_CLK:
> +   freq = qcom_find_freq(ftbl_gcc_sdcc2_apps_clk_src, rate);
> +   clk_rcg_set_rate_mnd(priv->base, 0x14018,
> +freq->pre_div, freq->m, freq->n, 
> freq->src, 8);
> +   return freq->freq;
> +   case GCC_USB30_PRIM_MASTER_CLK:
> +   freq = qcom_find_freq(ftbl_gcc_usb30_prim_master_clk_src, 

Re: [PATCH 1/3] clk: qcom: Add SM8550 clock driver

2024-04-10 Thread Sumit Garg
Hi Neil,

On Thu, 4 Apr 2024 at 22:16, Neil Armstrong  wrote:
>
> Add the GCC and TCSRCC clock driver for the SM8550 SoC.
>
> The GCC driver uses the clk-qcom infrastructure to support GDSCs,
> Resets and gates. While the TCSRCC is a simpler clock driver which
> only supports gates.
>
> The GCC enable and set_rate callbacks contains some tweaks to
> setup clocks for Debug UART, SDCard controller and USB.

Okay so these are the peripherals you intend to support to begin with.

>
> The TCSRCC gates returns the XO frequency, which is used by the
> Synopsys eUSB2 driver to determine the PHY configuration.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/clk/qcom/Kconfig|   8 +
>  drivers/clk/qcom/Makefile   |   1 +
>  drivers/clk/qcom/clock-sm8550.c | 335 
> 
>  3 files changed, 344 insertions(+)
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 8dae635ac2c..c908a3d19c9 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -47,6 +47,14 @@ config CLK_QCOM_SDM845
>   on the Snapdragon 845 SoC. This driver supports the clocks
>   and resets exposed by the GCC hardware block.
>
> +config CLK_QCOM_SM8550
> +   bool "Qualcomm SM8550 GCC"
> +   select CLK_QCOM
> +   help
> + Say Y here to enable support for the Global Clock Controller
> + on the Snapdragon SM8550 SoC. This driver supports the clocks
> + and resets exposed by the GCC hardware block.
> +
>  endmenu
>
>  endif
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index cb179fdac58..d9ac5719f49 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_CLK_QCOM_APQ8016) += clock-apq8016.o
>  obj-$(CONFIG_CLK_QCOM_APQ8096) += clock-apq8096.o
>  obj-$(CONFIG_CLK_QCOM_IPQ4019) += clock-ipq4019.o
>  obj-$(CONFIG_CLK_QCOM_QCS404) += clock-qcs404.o
> +obj-$(CONFIG_CLK_QCOM_SM8550) += clock-sm8550.o
> diff --git a/drivers/clk/qcom/clock-sm8550.c b/drivers/clk/qcom/clock-sm8550.c
> new file mode 100644
> index 000..c0249925cc7
> --- /dev/null
> +++ b/drivers/clk/qcom/clock-sm8550.c
> @@ -0,0 +1,335 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Clock drivers for Qualcomm sm8550
> + *
> + * (C) Copyright 2024 Linaro Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clock-qcom.h"
> +
> +/* On-board TCXO, TOFIX get from DT */
> +#define TCXO_RATE  3840
> +
> +/* bi_tcxo_div2 divided after RPMh output */
> +#define TCXO_DIV2_RATE (TCXO_RATE / 2)
> +
> +static const struct freq_tbl ftbl_gcc_qupv3_wrap1_s2_clk_src[] = {
> +   F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
> +   F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
> +   F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
> +   F(29491200, CFG_CLK_SRC_GPLL0_EVEN, 1, 1536, 15625),
> +   F(3200, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 75),
> +   F(4800, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 25),
> +   F(5120, CFG_CLK_SRC_GPLL0_EVEN, 1, 64, 375),
> +   F(6400, CFG_CLK_SRC_GPLL0_EVEN, 1, 16, 75),
> +   F(7500, CFG_CLK_SRC_GPLL0_EVEN, 4, 0, 0),
> +   F(8000, CFG_CLK_SRC_GPLL0_EVEN, 1, 4, 15),
> +   F(9600, CFG_CLK_SRC_GPLL0_EVEN, 1, 8, 25),
> +   F(1, CFG_CLK_SRC_GPLL0, 6, 0, 0),
> +   { }
> +};
> +
> +static const struct freq_tbl ftbl_gcc_sdcc2_apps_clk_src[] = {
> +   F(40, CFG_CLK_SRC_CXO, 12, 1, 4),
> +   F(2500, CFG_CLK_SRC_GPLL0_EVEN, 12, 0, 0),
> +   F(3750, CFG_CLK_SRC_GPLL0_EVEN, 8, 0, 0),
> +   F(5000, CFG_CLK_SRC_GPLL0_EVEN, 6, 0, 0),
> +   F(1, CFG_CLK_SRC_GPLL0_EVEN, 3, 0, 0),
> +   /* TOFIX F(20200, CFG_CLK_SRC_GPLL9, 4, 0, 0), */
> +   { }
> +};
> +
> +static const struct freq_tbl ftbl_gcc_usb30_prim_master_clk_src[] = {
> +   F(6667, CFG_CLK_SRC_GPLL0_EVEN, 4.5, 0, 0),
> +   F(1, CFG_CLK_SRC_GPLL0, 4.5, 0, 0),
> +   F(2, CFG_CLK_SRC_GPLL0, 3, 0, 0),
> +   F(24000, CFG_CLK_SRC_GPLL0, 2.5, 0, 0),
> +   { }
> +};
> +
> +static ulong sm8550_set_rate(struct clk *clk, ulong rate)
> +{
> +   struct msm_clk_priv *priv = dev_get_priv(clk->dev);
> +   const struct freq_tbl *freq;
> +
> +   switch (clk->id) {
> +   case GCC_QUPV3_WRAP1_S7_CLK: /* UART7 */
> +   freq = qcom_find_freq(ftbl_gcc_qupv3_wrap1_s2_clk_src, rate);
> +   clk_rcg_set_rate_mnd(priv->base, 0x18898,
> +freq->pre_div, freq->m, freq->n, 
> freq->src, 16);
> +   return freq->freq;
> +   case GCC_SDCC2_APPS_CLK:
> +   freq = qcom_find_freq(ftbl_gcc_sdcc2_apps_clk_src, rate);
> +   clk_rcg_set_rate_mnd(priv->base, 0x14018,
> +freq->pre_div, freq->m, freq->n, 
> freq->src, 8);
> +  

Re: [PATCH v3 6/6] board: add support for Schneider HMIBSC board

2024-04-08 Thread Sumit Garg
On Fri, 5 Apr 2024 at 20:16, Stephan Gerhold  wrote:
>
> On Fri, Apr 05, 2024 at 02:37:42PM +0530, Sumit Garg wrote:
> > Support for Schneider Electric HMIBSC. Features:
> > - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
> > - 2GiB RAM
> > - 64GiB eMMC, SD slot
> > - WiFi and Bluetooth
> > - 2x Host, 1x Device USB port
> > - HDMI
> > - Discrete TPM2 chip over SPI
> >
> > Features enabled in U-Boot:
> > - RAUC updates
> > - Environment protection
> > - USB based ethernet adaptors
> >
> > Signed-off-by: Sumit Garg 
>
> I don't think this is a big deal but this patch would be a bit easier to
> skim over if you move the (unmodified?) import of the Linux
> apq8016-schneider-hmibsc.dts to a separate patch with a clear note in
> the commit message
>
>  - where it comes from (link to Linux patch), and
>  - that it can be removed again with a future update of the upstream DTs
>in U-Boot (once it is applied upstream at least).
>
> You kind of have that information in the cover letter but I think it
> would be good to have it in the commit message.

Although the general practice in U-Boot is to have the board DTS file
submitted along with board code, if it makes review easier via
separating the unmodified import of the board DTS file then I can do
that.

>
> > ---
> >  arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
> >  board/schneider/hmibsc/MAINTAINERS|   6 +
> >  configs/hmibsc_defconfig  |  86 
> >  doc/board/index.rst   |   1 +
> >  doc/board/schneider/hmibsc.rst|  45 ++
> >  doc/board/schneider/index.rst |   9 +
> >  include/configs/hmibsc.h  |  57 +++
> >  7 files changed, 695 insertions(+)
> >  create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts
> >  create mode 100644 board/schneider/hmibsc/MAINTAINERS
> >  create mode 100644 configs/hmibsc_defconfig
> >  create mode 100644 doc/board/schneider/hmibsc.rst
> >  create mode 100644 doc/board/schneider/index.rst
> >  create mode 100644 include/configs/hmibsc.h
> >
> > [...]
> > diff --git a/include/configs/hmibsc.h b/include/configs/hmibsc.h
> > new file mode 100644
> > index 000..66dfa549ce1
> > --- /dev/null
> > +++ b/include/configs/hmibsc.h
> > @@ -0,0 +1,57 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Board configuration file for HMIBSC
> > + *
> > + * (C) Copyright 2024 Sumit Garg 
> > + */
> > +
> > +#ifndef __CONFIGS_HMIBSC_H
> > +#define __CONFIGS_HMIBSC_H
> > +
> > +/* PHY needs a longer aneg time */
> > +#define PHY_ANEG_TIMEOUT 8000
> > +
> > +#define HMIBSC_BOOTCOMMAND \
> > + "setenv devtype mmc; setenv devnum 0; " \
> > + "test -n \"${BOOT_ORDER}\" || setenv BOOT_ORDER \"A B\"; " \
> > + "test -n \"${BOOT_A_LEFT}\" || setenv BOOT_A_LEFT 3; " \
> > + "test -n \"${BOOT_B_LEFT}\" || setenv BOOT_B_LEFT 3; " \
> > + "setenv raucslot; " \
> > + "for BOOT_SLOT in \"${BOOT_ORDER}\"; do " \
> > + "  if test \"x${raucslot}\" != \"x\"; then " \
> > + "  echo \"skip remaining slots...\"; " \
> > + "  elif test \"x${BOOT_SLOT}\" = \"xA\"; then " \
> > + "if test ${BOOT_A_LEFT} -gt 0; then " \
> > + "  setexpr BOOT_A_LEFT ${BOOT_A_LEFT} - 1; " \
> > + "  echo \"Found valid RAUC slot A\"; " \
> > + "  setenv raucslot \"rauc.slot=A\"; " \
> > + "  setenv raucpart A; setenv distro_bootpart 6;" \
> > + "fi; " \
> > + "  elif test \"x${BOOT_SLOT}\" = \"xB\"; then " \
> > + "if test ${BOOT_B_LEFT} -gt 0; then " \
> > + "  setexpr BOOT_B_LEFT ${BOOT_B_LEFT} - 1; " \
> > + "  echo \"Found valid RAUC slot B\"; " \
> > + "  setenv raucslot \"rauc.slot=B\"; " \
> > + "  setenv raucpart B; setenv distro_bootpart 7;" \
> > + "fi; " \
> > + "  fi; " \
> > + "done; " \
> > + "if test -n \"${raucslot}\"; then " \
> > + "  setenv bootargs console=ttyMSM1 root=PARTLABEL=rootfs_${raucpart} 
> > rw rootwait ${raucslot};

Re: [RFC PATCH 01/15] DO-NOT-MERGE: dts: upstream: src: Necessary pulls from upstream dts

2024-04-05 Thread Sumit Garg
On Fri, 5 Apr 2024 at 11:17, Jayesh Choudhary  wrote:
>
> Hello Sumit,
>
> On 05/04/24 10:27, Sumit Garg wrote:
> > Hi Jayesh,
> >
> > On Thu, 4 Apr 2024 at 14:30, Jayesh Choudhary  wrote:
> >>
> >> j722s dts support that needs to be pulled from devicetree-rebasing
> >> tree. The whole series depends on this support.
> >>
> >
> > Which devicetree-rebasing tag does this patch depend upon? v6.8-dts
> > has already made its way to U-Boot mainline [1].
> >
> > [1] 
> > https://source.denx.de/u-boot/u-boot/-/commit/bc39e06778168a34bb4e0a34fbee4edbde4414d8
> >
>
> These patches are on top of the next branch (same commit)
> The required patches[0][2][3] are in tag v6.9-rc1-dts.
>

Okay, the next sync is expected to happen when U-Boot next branch
opens again and I suppose during that time frame only Linux kernel
v6.9 will be released. If you are targeting the U-Boot July release
then you have to opt out of OF_UPSTREAM.

-Sumit

> [0]:
> <https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/commit/?id=1339c374a4c10f184d2bb4c6dadd3155f9260599>
> [2]:
> <https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/commit/?id=4dd9e11aa40f6d7bb2bd4993a8ddf17c935c9686>
> [3]:
> <https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/commit/?id=ec136bb18fcc85d32787530bc065bd97ee3bba60>
>
> -Jayesh
>
>
> > -Sumit
> >
> >> Signed-off-by: Jayesh Choudhary 
> >> ---
> >>   dts/upstream/Bindings/arm/ti/k3.yaml   |   6 +
> >>   dts/upstream/src/arm64/ti/k3-j722s-evm.dts | 383 +
> >>   dts/upstream/src/arm64/ti/k3-j722s.dtsi|  89 +
> >>   dts/upstream/src/arm64/ti/k3-pinctrl.h |   3 +
> >>   4 files changed, 481 insertions(+)
> >>   create mode 100644 dts/upstream/src/arm64/ti/k3-j722s-evm.dts
> >>   create mode 100644 dts/upstream/src/arm64/ti/k3-j722s.dtsi
> >>
> >> diff --git a/dts/upstream/Bindings/arm/ti/k3.yaml 
> >> b/dts/upstream/Bindings/arm/ti/k3.yaml
> >> index c6506bccfe..d526723484 100644
> >> --- a/dts/upstream/Bindings/arm/ti/k3.yaml
> >> +++ b/dts/upstream/Bindings/arm/ti/k3.yaml
> >> @@ -123,6 +123,12 @@ properties:
> >> - ti,j721s2-evm
> >> - const: ti,j721s2
> >>
> >> +  - description: K3 J722S SoC and Boards
> >> +items:
> >> +  - enum:
> >> +  - ti,j722s-evm
> >> +  - const: ti,j722s
> >> +
> >> - description: K3 J784s4 SoC
> >>   items:
> >> - enum:
>
> [...]


[PATCH v3 6/6] board: add support for Schneider HMIBSC board

2024-04-05 Thread Sumit Garg
Support for Schneider Electric HMIBSC. Features:
- Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
- 2GiB RAM
- 64GiB eMMC, SD slot
- WiFi and Bluetooth
- 2x Host, 1x Device USB port
- HDMI
- Discrete TPM2 chip over SPI

Features enabled in U-Boot:
- RAUC updates
- Environment protection
- USB based ethernet adaptors

Signed-off-by: Sumit Garg 
---
 arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
 board/schneider/hmibsc/MAINTAINERS|   6 +
 configs/hmibsc_defconfig  |  86 
 doc/board/index.rst   |   1 +
 doc/board/schneider/hmibsc.rst|  45 ++
 doc/board/schneider/index.rst |   9 +
 include/configs/hmibsc.h  |  57 +++
 7 files changed, 695 insertions(+)
 create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts
 create mode 100644 board/schneider/hmibsc/MAINTAINERS
 create mode 100644 configs/hmibsc_defconfig
 create mode 100644 doc/board/schneider/hmibsc.rst
 create mode 100644 doc/board/schneider/index.rst
 create mode 100644 include/configs/hmibsc.h

diff --git a/arch/arm/dts/apq8016-schneider-hmibsc.dts 
b/arch/arm/dts/apq8016-schneider-hmibsc.dts
new file mode 100644
index 000..75c6137e5a1
--- /dev/null
+++ b/arch/arm/dts/apq8016-schneider-hmibsc.dts
@@ -0,0 +1,491 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include "msm8916-pm8916.dtsi"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Schneider Electric HMIBSC Board";
+   compatible = "schneider,apq8016-hmibsc", "qcom,apq8016";
+
+   aliases {
+   i2c1 = _i2c6;
+   i2c3 = _i2c4;
+   i2c4 = _i2c3;
+   mmc0 = _1; /* eMMC */
+   mmc1 = _2; /* SD card */
+   serial0 = _uart1;
+   serial1 = _uart2;
+   spi0 = _spi5;
+   usid0 = _0;
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   autorepeat;
+   pinctrl-0 = <_key_volp_n_default>;
+   pinctrl-names = "default";
+
+   button {
+   label = "Volume Up";
+   linux,code = ;
+   gpios = < 107 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-0 = <_mpps_leds>;
+   pinctrl-names = "default";
+
+   led-1 {
+   function = LED_FUNCTION_WLAN;
+   color = ;
+   gpios = <_mpps 2 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "phy0tx";
+   default-state = "off";
+   };
+
+   led-2 {
+   function = LED_FUNCTION_BLUETOOTH;
+   color = ;
+   gpios = <_mpps 3 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "bluetooth-power";
+   default-state = "off";
+   };
+   };
+
+   memory@8000 {
+   reg = <0 0x8000 0 0x4000>;
+   };
+
+   reserved-memory {
+   ramoops@bff0 {
+   compatible = "ramoops";
+   reg = <0x0 0xbff0 0x0 0x10>;
+   record-size = <0x2>;
+   console-size = <0x2>;
+   ftrace-size = <0x2>;
+   ecc-size = <16>;
+   };
+   };
+
+   usb-hub {
+   compatible = "smsc,usb3503";
+   reset-gpios = <_gpios 1 GPIO_ACTIVE_LOW>;
+   initial-mode = <1>;
+   };
+
+   usb_id: usb-id {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpios = < 110 GPIO_ACTIVE_HIGH>;
+   pinctrl-0 = <_id_default>;
+   pinctrl-names = "default";
+   };
+};
+
+_i2c3 {
+   status = "okay";
+
+   eeprom@50 {
+   compatible = "atmel,24c32";
+   reg = <0x50>;
+   };
+};
+
+_i2c4 {
+   status = "okay";
+
+   adv_bridge: bridge@39 {
+   c

[PATCH v3 5/6] pinctrl: qcom: apq8016: Add GPIO pinctrl function

2024-04-05 Thread Sumit Garg
Add GPIO pinctrl function to enable driving GPIO pins as output low or
high.

Signed-off-by: Sumit Garg 
---
 drivers/pinctrl/qcom/pinctrl-apq8016.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c 
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index 1ee8b7db1a2..b14a8921af4 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -29,6 +29,7 @@ static const char * const msm_pinctrl_pins[] = {
 };
 
 static const struct pinctrl_function msm_pinctrl_functions[] = {
+   {"gpio", 0},
{"blsp_uart1", 2},
{"blsp_uart2", 2},
 };
-- 
2.34.1



[PATCH v3 4/6] pinctrl: qcom: Add support for driving GPIO pins output

2024-04-05 Thread Sumit Garg
Add support for driving the GPIO pins as output low or high.

Signed-off-by: Sumit Garg 
---
 drivers/pinctrl/qcom/pinctrl-qcom.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-qcom.c 
b/drivers/pinctrl/qcom/pinctrl-qcom.c
index 909e566acf5..e68971b37ff 100644
--- a/drivers/pinctrl/qcom/pinctrl-qcom.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcom.c
@@ -29,15 +29,24 @@ struct msm_pinctrl_priv {
 #define GPIO_CONFIG_REG(priv, x) \
(qcom_pin_offset((priv)->data->pin_data.pin_offsets, x))
 
-#define TLMM_GPIO_PULL_MASK GENMASK(1, 0)
-#define TLMM_FUNC_SEL_MASK GENMASK(5, 2)
-#define TLMM_DRV_STRENGTH_MASK GENMASK(8, 6)
-#define TLMM_GPIO_DISABLE BIT(9)
+#define GPIO_IN_OUT_REG(priv, x) \
+   (GPIO_CONFIG_REG(priv, x) + 0x4)
+
+#define TLMM_GPIO_PULL_MASKGENMASK(1, 0)
+#define TLMM_FUNC_SEL_MASK GENMASK(5, 2)
+#define TLMM_DRV_STRENGTH_MASK GENMASK(8, 6)
+#define TLMM_GPIO_OUTPUT_MASK  BIT(1)
+#define TLMM_GPIO_OE_MASK  BIT(9)
+
+/* GPIO register shifts. */
+#define GPIO_OUT_SHIFT 1
 
 static const struct pinconf_param msm_conf_params[] = {
{ "drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 2 },
{ "bias-disable", PIN_CONFIG_BIAS_DISABLE, 0 },
{ "bias-pull-up", PIN_CONFIG_BIAS_PULL_UP, 3 },
+   { "output-high", PIN_CONFIG_OUTPUT, 1, },
+   { "output-low", PIN_CONFIG_OUTPUT, 0, },
 };
 
 static int msm_get_functions_count(struct udevice *dev)
@@ -90,7 +99,7 @@ static int msm_pinmux_set(struct udevice *dev, unsigned int 
pin_selector,
return 0;
 
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
-   TLMM_FUNC_SEL_MASK | TLMM_GPIO_DISABLE, func << 2);
+   TLMM_FUNC_SEL_MASK | TLMM_GPIO_OE_MASK, func << 2);
return 0;
 }
 
@@ -117,6 +126,12 @@ static int msm_pinconf_set(struct udevice *dev, unsigned 
int pin_selector,
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(priv, 
pin_selector),
TLMM_GPIO_PULL_MASK, argument);
break;
+   case PIN_CONFIG_OUTPUT:
+   writel(argument << GPIO_OUT_SHIFT,
+  priv->base + GPIO_IN_OUT_REG(priv, pin_selector));
+   setbits_le32(priv->base + GPIO_CONFIG_REG(priv, pin_selector),
+TLMM_GPIO_OE_MASK);
+   break;
default:
return 0;
}
-- 
2.34.1



[PATCH v3 3/6] serial_msm: Enable RS232 flow control

2024-04-05 Thread Sumit Garg
SE HMIBSC board debug console requires RS232 flow control, so enable
corresponding support if RS232 gpios are present.

Reviewed-by: Caleb Connolly 
Signed-off-by: Sumit Garg 
---
 drivers/serial/serial_msm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index 4de10e75191..3142ecf7362 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -53,10 +53,11 @@
 #define UARTDM_TF   0x100 /* UART Transmit FIFO register */
 #define UARTDM_RF   0x140 /* UART Receive FIFO register */
 
-#define UART_DM_CLK_RX_TX_BIT_RATE 0xCC
-#define MSM_BOOT_UART_DM_8_N_1_MODE 0x34
-#define MSM_BOOT_UART_DM_CMD_RESET_RX 0x10
-#define MSM_BOOT_UART_DM_CMD_RESET_TX 0x20
+#define UART_DM_CLK_RX_TX_BIT_RATE 0xCC
+#define MSM_BOOT_UART_DM_8_N_1_MODE0x34
+#define MSM_BOOT_UART_DM_CMD_RESET_RX  0x10
+#define MSM_BOOT_UART_DM_CMD_RESET_TX  0x20
+#define MSM_UART_MR1_RX_RDY_CTLBIT(7)
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -182,7 +183,9 @@ static void uart_dm_init(struct msm_serial_data *priv)
mdelay(5);
 
writel(priv->clk_bit_rate, priv->base + UARTDM_CSR);
-   writel(0x0, priv->base + UARTDM_MR1);
+
+   /* Enable RS232 flow control to support RS232 db9 connector */
+   writel(MSM_UART_MR1_RX_RDY_CTL, priv->base + UARTDM_MR1);
writel(MSM_BOOT_UART_DM_8_N_1_MODE, priv->base + UARTDM_MR2);
writel(MSM_BOOT_UART_DM_CMD_RESET_RX, priv->base + UARTDM_CR);
writel(MSM_BOOT_UART_DM_CMD_RESET_TX, priv->base + UARTDM_CR);
-- 
2.34.1



[PATCH v3 2/6] apq8016: Add support for UART1 clocks and pinmux

2024-04-05 Thread Sumit Garg
SE HMIBSC board uses UART1 as the main debug console, so add
corresponding clocks and pinmux support. Along with that update
instructions to enable clocks for debug UART support.

Signed-off-by: Sumit Garg 
---
 drivers/clk/qcom/clock-apq8016.c   | 38 ++
 drivers/pinctrl/qcom/pinctrl-apq8016.c |  1 +
 drivers/serial/serial_msm.c| 11 ++--
 3 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index 5a5868169c8..9556b94774a 100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -31,7 +31,8 @@
 #define BLSP1_AHB_CBCR 0x1008
 
 /* Uart clock control registers */
-#define BLSP1_UART2_BCR(0x3028)
+#define BLSP1_UART1_APPS_CBCR  (0x203C)
+#define BLSP1_UART1_APPS_CMD_RCGR  (0x2044)
 #define BLSP1_UART2_APPS_CBCR  (0x302C)
 #define BLSP1_UART2_APPS_CMD_RCGR  (0x3034)
 
@@ -52,7 +53,7 @@ static struct vote_clk gcc_blsp1_ahb_clk = {
 };
 
 /* SDHCI */
-static int clk_init_sdc(struct msm_clk_priv *priv, int slot, uint rate)
+static int apq8016_clk_init_sdc(struct msm_clk_priv *priv, int slot, uint rate)
 {
int div = 15; /* 100MHz default */
 
@@ -70,20 +71,35 @@ static int clk_init_sdc(struct msm_clk_priv *priv, int 
slot, uint rate)
 }
 
 /* UART: 115200 */
-int apq8016_clk_init_uart(phys_addr_t base)
+int apq8016_clk_init_uart(phys_addr_t base, unsigned long id)
 {
+   u32 cmd_rcgr, apps_cbcr;
+
+   switch (id) {
+   case GCC_BLSP1_UART1_APPS_CLK:
+   cmd_rcgr = BLSP1_UART1_APPS_CMD_RCGR;
+   apps_cbcr = BLSP1_UART1_APPS_CBCR;
+   break;
+   case GCC_BLSP1_UART2_APPS_CLK:
+   cmd_rcgr = BLSP1_UART2_APPS_CMD_RCGR;
+   apps_cbcr = BLSP1_UART2_APPS_CBCR;
+   break;
+   default:
+   return 0;
+   }
+
/* Enable AHB clock */
clk_enable_vote_clk(base, _blsp1_ahb_clk);
 
/* 7372800 uart block clock @ GPLL0 */
-   clk_rcg_set_rate_mnd(base, BLSP1_UART2_APPS_CMD_RCGR, 1, 144, 15625,
-CFG_CLK_SRC_GPLL0, 16);
+   clk_rcg_set_rate_mnd(base, cmd_rcgr, 1, 144, 15625, CFG_CLK_SRC_GPLL0,
+16);
 
/* Vote for gpll0 clock */
clk_enable_gpll0(base, _vote_clk);
 
/* Enable core clk */
-   clk_enable_cbc(base + BLSP1_UART2_APPS_CBCR);
+   clk_enable_cbc(base + apps_cbcr);
 
return 0;
 }
@@ -94,14 +110,12 @@ static ulong apq8016_clk_set_rate(struct clk *clk, ulong 
rate)
 
switch (clk->id) {
case GCC_SDCC1_APPS_CLK: /* SDC1 */
-   return clk_init_sdc(priv, 0, rate);
-   break;
+   return apq8016_clk_init_sdc(priv, 0, rate);
case GCC_SDCC2_APPS_CLK: /* SDC2 */
-   return clk_init_sdc(priv, 1, rate);
-   break;
+   return apq8016_clk_init_sdc(priv, 1, rate);
+   case GCC_BLSP1_UART1_APPS_CLK: /* UART1 */
case GCC_BLSP1_UART2_APPS_CLK: /* UART2 */
-   return apq8016_clk_init_uart(priv->base);
-   break;
+   return apq8016_clk_init_uart(priv->base, clk->id);
default:
return 0;
}
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8016.c 
b/drivers/pinctrl/qcom/pinctrl-apq8016.c
index a9a00f4b081..1ee8b7db1a2 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8016.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8016.c
@@ -29,6 +29,7 @@ static const char * const msm_pinctrl_pins[] = {
 };
 
 static const struct pinctrl_function msm_pinctrl_functions[] = {
+   {"blsp_uart1", 2},
{"blsp_uart2", 2},
 };
 
diff --git a/drivers/serial/serial_msm.c b/drivers/serial/serial_msm.c
index ac4280c6c4c..4de10e75191 100644
--- a/drivers/serial/serial_msm.c
+++ b/drivers/serial/serial_msm.c
@@ -248,12 +248,17 @@ static struct msm_serial_data init_serial_data = {
 #include 
 
 /* Uncomment to turn on UART clocks when debugging U-Boot as aboot on MSM8916 
*/
-//int apq8016_clk_init_uart(phys_addr_t gcc_base);
+//int apq8016_clk_init_uart(phys_addr_t gcc_base, unsigned long id);
 
 static inline void _debug_uart_init(void)
 {
-   /* Uncomment to turn on UART clocks when debugging U-Boot as aboot on 
MSM8916 */
-   //apq8016_clk_init_uart(0x180);
+   /*
+* Uncomment to turn on UART clocks when debugging U-Boot as aboot
+* on MSM8916. Supported debug UART clock IDs:
+*   - db410c: GCC_BLSP1_UART2_APPS_CLK
+*   - HMIBSC: GCC_BLSP1_UART1_APPS_CLK
+*/
+   //apq8016_clk_init_uart(0x180, );
uart_dm_init(_serial_data);
 }
 
-- 
2.34.1



[PATCH v3 1/6] qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default

2024-04-05 Thread Sumit Garg
Enabling LINUX_KERNEL_IMAGE_HEADER by default doesn't allow
ENABLE_ARM_SOC_BOOT0_HOOK to work properly on db410c when U-Boot is
loaded as a first stage bootloader. It leads to secondary CPUs bringup
failure and later causing the Linux kernel to freeze.

So fix it via selectively enabling LINUX_KERNEL_IMAGE_HEADER where it's
actually required.

Fixes: 059d526af312 ("mach-snapdragon: generalise board support")
Reviewed-by: Caleb Connolly 
Signed-off-by: Sumit Garg 
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4cdf08dd695..08ae7e51a6d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1088,7 +1088,7 @@ config ARCH_SNAPDRAGON
select BOARD_LATE_INIT
select OF_BOARD
select SAVE_PREV_BL_FDT_ADDR
-   select LINUX_KERNEL_IMAGE_HEADER
+   select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
imply CMD_DM
 
 config ARCH_SOCFPGA
-- 
2.34.1



[PATCH v3 0/6] Add SE HMBSC board support

2024-04-05 Thread Sumit Garg
SE HMIBSC board is based on Qcom APQ8016 SoC. One of the major
difference from db410c is serial port where HMIBSC board uses UART1 as
the debug console with an RS232 port, patch #2 - #5 adds corresponding
driver support.

Patch #6 adds main HMIBSC board specific bits, features:
- Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
- 2GiB RAM
- 64GiB eMMC, SD slot
- WiFi and Bluetooth
- 2x Host, 1x Device USB port
- HDMI
- Discrete TPM2 chip over SPI

Features enabled in U-Boot:
- RAUC updates (refer [2] for more details)
- Environment protection
- USB based ethernet adaptors

Feedback is very much welcome.

Changes in v3:
- Rebased on top of qcom-next [1].
- Collected some review tags.
- Incorporated misc. comments from Caleb and Stephen.
- Split patch#4 as requested.
- Linux HMIBSC board DTS has already been reviewed here [3], I have
  incorporated that for U-Boot too.

Changes in v2:
- Rebased on top on qcom-next [1].
- Added patch#1 as a fix for generic qcom board support.
- Added patch#4 to enable driving GPIO pins based on pinctrl
  configuration. This replaces the custom GPIO configuration.
- Added proper DTS file for HMIBSC board based on Linux DT pattern.
- Merged board support patches into a single patch#5.

[1] 
https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-next?ref_type=heads
[2] https://rauc.readthedocs.io/en/latest/
[3] 
https://lore.kernel.org/linux-kernel/20240403043416.3800259-4-sumit.g...@linaro.org/

Sumit Garg (6):
  qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default
  apq8016: Add support for UART1 clocks and pinmux
  serial_msm: Enable RS232 flow control
  pinctrl: qcom: Add support for driving GPIO pins output
  pinctrl: qcom: apq8016: Add GPIO pinctrl function
  board: add support for Schneider HMIBSC board

 arch/arm/Kconfig  |   2 +-
 arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++
 board/schneider/hmibsc/MAINTAINERS|   6 +
 configs/hmibsc_defconfig  |  86 
 doc/board/index.rst   |   1 +
 doc/board/schneider/hmibsc.rst|  45 ++
 doc/board/schneider/index.rst |   9 +
 drivers/clk/qcom/clock-apq8016.c  |  38 +-
 drivers/pinctrl/qcom/pinctrl-apq8016.c|   2 +
 drivers/pinctrl/qcom/pinctrl-qcom.c   |  25 +-
 drivers/serial/serial_msm.c   |  24 +-
 include/configs/hmibsc.h  |  57 +++
 12 files changed, 760 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts
 create mode 100644 board/schneider/hmibsc/MAINTAINERS
 create mode 100644 configs/hmibsc_defconfig
 create mode 100644 doc/board/schneider/hmibsc.rst
 create mode 100644 doc/board/schneider/index.rst
 create mode 100644 include/configs/hmibsc.h

-- 
2.34.1



Re: [RFC PATCH 01/15] DO-NOT-MERGE: dts: upstream: src: Necessary pulls from upstream dts

2024-04-04 Thread Sumit Garg
Hi Jayesh,

On Thu, 4 Apr 2024 at 14:30, Jayesh Choudhary  wrote:
>
> j722s dts support that needs to be pulled from devicetree-rebasing
> tree. The whole series depends on this support.
>

Which devicetree-rebasing tag does this patch depend upon? v6.8-dts
has already made its way to U-Boot mainline [1].

[1] 
https://source.denx.de/u-boot/u-boot/-/commit/bc39e06778168a34bb4e0a34fbee4edbde4414d8

-Sumit

> Signed-off-by: Jayesh Choudhary 
> ---
>  dts/upstream/Bindings/arm/ti/k3.yaml   |   6 +
>  dts/upstream/src/arm64/ti/k3-j722s-evm.dts | 383 +
>  dts/upstream/src/arm64/ti/k3-j722s.dtsi|  89 +
>  dts/upstream/src/arm64/ti/k3-pinctrl.h |   3 +
>  4 files changed, 481 insertions(+)
>  create mode 100644 dts/upstream/src/arm64/ti/k3-j722s-evm.dts
>  create mode 100644 dts/upstream/src/arm64/ti/k3-j722s.dtsi
>
> diff --git a/dts/upstream/Bindings/arm/ti/k3.yaml 
> b/dts/upstream/Bindings/arm/ti/k3.yaml
> index c6506bccfe..d526723484 100644
> --- a/dts/upstream/Bindings/arm/ti/k3.yaml
> +++ b/dts/upstream/Bindings/arm/ti/k3.yaml
> @@ -123,6 +123,12 @@ properties:
>- ti,j721s2-evm
>- const: ti,j721s2
>
> +  - description: K3 J722S SoC and Boards
> +items:
> +  - enum:
> +  - ti,j722s-evm
> +  - const: ti,j722s
> +
>- description: K3 J784s4 SoC
>  items:
>- enum:
> diff --git a/dts/upstream/src/arm64/ti/k3-j722s-evm.dts 
> b/dts/upstream/src/arm64/ti/k3-j722s-evm.dts
> new file mode 100644
> index 00..cee3a8661d
> --- /dev/null
> +++ b/dts/upstream/src/arm64/ti/k3-j722s-evm.dts
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Device Tree file for the J722S EVM
> + * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
> + *
> + * Schematics: https://www.ti.com/lit/zip/sprr495
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include "k3-j722s.dtsi"
> +
> +/ {
> +   compatible = "ti,j722s-evm", "ti,j722s";
> +   model = "Texas Instruments J722S EVM";
> +
> +   aliases {
> +   serial0 = _uart0;
> +   serial2 = _uart0;
> +   mmc0 = 
> +   mmc1 = 
> +   };
> +
> +   chosen {
> +   stdout-path = _uart0;
> +   };
> +
> +   memory@8000 {
> +   /* 8G RAM */
> +   reg = <0x 0x8000 0x 0x8000>,
> + <0x0008 0x8000 0x0001 0x8000>;
> +   device_type = "memory";
> +   bootph-pre-ram;
> +   };
> +
> +   reserved_memory: reserved-memory {
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   ranges;
> +
> +   secure_tfa_ddr: tfa@9e78 {
> +   reg = <0x00 0x9e78 0x00 0x8>;
> +   no-map;
> +   };
> +
> +   secure_ddr: optee@9e80 {
> +   reg = <0x00 0x9e80 0x00 0x0180>;
> +   no-map;
> +   };
> +
> +   wkup_r5fss0_core0_memory_region: r5f-memory@a010 {
> +   compatible = "shared-dma-pool";
> +   reg = <0x00 0xa010 0x00 0xf0>;
> +   no-map;
> +   };
> +
> +   };
> +
> +   vmain_pd: regulator-0 {
> +   /* TPS65988 PD CONTROLLER OUTPUT */
> +   compatible = "regulator-fixed";
> +   regulator-name = "vmain_pd";
> +   regulator-min-microvolt = <500>;
> +   regulator-max-microvolt = <500>;
> +   regulator-always-on;
> +   regulator-boot-on;
> +   bootph-all;
> +   };
> +
> +   vsys_5v0: regulator-vsys5v0 {
> +   /* Output of LM5140 */
> +   compatible = "regulator-fixed";
> +   regulator-name = "vsys_5v0";
> +   regulator-min-microvolt = <500>;
> +   regulator-max-microvolt = <500>;
> +   vin-supply = <_pd>;
> +   regulator-always-on;
> +   regulator-boot-on;
> +   };
> +
> +   vdd_mmc1: regulator-mmc1 {
> +   /* TPS22918DBVR */
> +   compatible = "regulator-fixed";
> +   regulator-name = "vdd_mmc1";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-boot-on;
> +   enable-active-high;
> +   gpio = < 15 GPIO_ACTIVE_HIGH>;
> +   bootph-all;
> +   };
> +
> +   vdd_sd_dv: regulator-TLV71033 {
> +   compatible = "regulator-gpio";
> +   regulator-name = "tlv71033";
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_sd_dv_pins_default>;
> +   regulator-min-microvolt = <180>;
> +   

Re: [PATCH v1] verdin-imx8mm/verdin-imx8mp: move imx verdins to OF_UPSTREAM

2024-04-04 Thread Sumit Garg
On Wed, 3 Apr 2024 at 12:51, Marcel Ziswiler  wrote:
>
> From: Marcel Ziswiler 
>
> Move verdin-imx8mm and verdin-imx8mp to OF_UPSTREAM:
> - handle the fact that dtbs now have a 'freescale/' prefix
> - imply OF_UPSTREAM
> - remove redundant files from arch/arm/dts leaving only the
>   *-u-boot.dtsi files
> - update MAINTAINERS files
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  arch/arm/dts/Makefile   |2 -
>  arch/arm/dts/imx8mm-verdin-dev.dtsi |  160 ---
>  arch/arm/dts/imx8mm-verdin-wifi-dev.dts |   18 -
>  arch/arm/dts/imx8mm-verdin-wifi.dtsi|   94 --
>  arch/arm/dts/imx8mm-verdin.dtsi | 1319 -
>  arch/arm/dts/imx8mp-verdin-dev.dtsi |  165 ---
>  arch/arm/dts/imx8mp-verdin-wifi-dev.dts |   18 -
>  arch/arm/dts/imx8mp-verdin-wifi.dtsi|   87 --
>  arch/arm/dts/imx8mp-verdin.dtsi | 1438 ---
>  arch/arm/mach-imx/imx8m/Kconfig |2 +
>  board/toradex/verdin-imx8mm/MAINTAINERS |4 -
>  board/toradex/verdin-imx8mp/MAINTAINERS |4 -
>  configs/verdin-imx8mm_defconfig |2 +-
>  configs/verdin-imx8mp_defconfig |2 +-
>  14 files changed, 4 insertions(+), 3311 deletions(-)
>  delete mode 100644 arch/arm/dts/imx8mm-verdin-dev.dtsi
>  delete mode 100644 arch/arm/dts/imx8mm-verdin-wifi-dev.dts
>  delete mode 100644 arch/arm/dts/imx8mm-verdin-wifi.dtsi
>  delete mode 100644 arch/arm/dts/imx8mm-verdin.dtsi
>  delete mode 100644 arch/arm/dts/imx8mp-verdin-dev.dtsi
>  delete mode 100644 arch/arm/dts/imx8mp-verdin-wifi-dev.dts
>  delete mode 100644 arch/arm/dts/imx8mp-verdin-wifi.dtsi
>  delete mode 100644 arch/arm/dts/imx8mp-verdin.dtsi
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 18fedc16740..cd8aa0b4143 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1082,7 +1082,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
> imx8mm-phg.dtb \
> imx8mm-phyboard-polis-rdk.dtb \
> imx8mm-phygate-tauri-l.dtb \
> -   imx8mm-verdin-wifi-dev.dtb \
> imx8mn-bsh-smm-s2.dtb \
> imx8mn-bsh-smm-s2pro.dtb \
> imx8mq-cm.dtb \
> @@ -1104,7 +1103,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
> imx8mp-icore-mx8mp-edimm2.2.dtb \
> imx8mp-msc-sm2s.dtb \
> imx8mp-phyboard-pollux-rdk.dtb \
> -   imx8mp-verdin-wifi-dev.dtb \
> imx8mq-pico-pi.dtb \
> imx8mq-kontron-pitx-imx8m.dtb \
> imx8mq-librem5-r4.dtb
> diff --git a/arch/arm/dts/imx8mm-verdin-dev.dtsi 
> b/arch/arm/dts/imx8mm-verdin-dev.dtsi
> deleted file mode 100644
> index 3c4b8ca125e..000
> --- a/arch/arm/dts/imx8mm-verdin-dev.dtsi
> +++ /dev/null
> @@ -1,160 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> -/*
> - * Copyright 2022 Toradex
> - */
> -
> -/ {
> -   sound_card: sound-card {
> -   compatible = "simple-audio-card";
> -   simple-audio-card,bitclock-master = <_master>;
> -   simple-audio-card,format = "i2s";
> -   simple-audio-card,frame-master = <_master>;
> -   simple-audio-card,mclk-fs = <256>;
> -   simple-audio-card,name = "imx8mm-nau8822";
> -   simple-audio-card,routing =
> -   "Headphones", "LHP",
> -   "Headphones", "RHP",
> -   "Speaker", "LSPK",
> -   "Speaker", "RSPK",
> -   "Line Out", "AUXOUT1",
> -   "Line Out", "AUXOUT2",
> -   "LAUX", "Line In",
> -   "RAUX", "Line In",
> -   "LMICP", "Mic In",
> -   "RMICP", "Mic In";
> -   simple-audio-card,widgets =
> -   "Headphones", "Headphones",
> -   "Line Out", "Line Out",
> -   "Speaker", "Speaker",
> -   "Microphone", "Mic In",
> -   "Line", "Line In";
> -
> -   dailink_master: simple-audio-card,codec {
> -   clocks = < IMX8MM_CLK_SAI2_ROOT>;
> -   sound-dai = <_1a>;
> -   };
> -
> -   simple-audio-card,cpu {
> -   sound-dai = <>;
> -   };
>

Re: [PATCH 1/3] arm64: imx: imx8mp-beacon: Migrate to OF_UPSTREAM

2024-04-03 Thread Sumit Garg
On Thu, 4 Apr 2024 at 08:29, Adam Ford  wrote:
>
> The imx8mp-beacon boards can migrate to OF_UPSTREAM which also
> allows for the removal the device tree files.
>
> Signed-off-by: Adam Ford 
>

For the series:

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d85a33055c..04ffa1f165 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1095,7 +1095,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
> imx8mn-beacon-kit.dtb \
> imx8mq-mnt-reform2.dtb \
> imx8mq-phanbell.dtb \
> -   imx8mp-beacon-kit.dtb \
> imx8mp-data-modul-edm-sbc.dtb \
> imx8mp-dhcom-som-overlay-rev100.dtbo \
> imx8mp-dhcom-som-overlay-eth1xfast.dtbo \
> diff --git a/arch/arm/dts/imx8mp-beacon-kit.dts 
> b/arch/arm/dts/imx8mp-beacon-kit.dts
> deleted file mode 100644
> index a08057410b..00
> --- a/arch/arm/dts/imx8mp-beacon-kit.dts
> +++ /dev/null
> @@ -1,783 +0,0 @@
> -// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> -/*
> - * Copyright 2023 Logic PD, Inc dba Beacon EmbeddedWorks
> - */
> -
> -/dts-v1/;
> -
> -#include 
> -#include 
> -#include "imx8mp.dtsi"
> -#include "imx8mp-beacon-som.dtsi"
> -
> -/ {
> -   model = "Beacon EmbeddedWorks i.MX8MPlus Development kit";
> -   compatible = "beacon,imx8mp-beacon-kit", "fsl,imx8mp";
> -
> -   aliases {
> -   ethernet0 = 
> -   ethernet1 = 
> -   };
> -
> -   chosen {
> -   stdout-path = 
> -   };
> -
> -   clk_xtal25: clock-xtal25 {
> -   compatible = "fixed-clock";
> -   #clock-cells = <0>;
> -   clock-frequency = <2500>;
> -   };
> -
> -   connector {
> -   compatible = "usb-c-connector";
> -   label = "USB-C";
> -   data-role = "dual";
> -
> -   ports {
> -   #address-cells = <1>;
> -   #size-cells = <0>;
> -
> -   port@0 {
> -   reg = <0>;
> -
> -   hs_ep: endpoint {
> -   remote-endpoint = <_hs_ep>;
> -   };
> -   };
> -   port@1 {
> -   reg = <1>;
> -
> -   ss_ep: endpoint {
> -   remote-endpoint = <_in_ep>;
> -   };
> -   };
> -   };
> -   };
> -
> -   dmic_codec: dmic-codec {
> -   compatible = "dmic-codec";
> -   num-channels = <1>;
> -   #sound-dai-cells = <0>;
> -   };
> -
> -   gpio-keys {
> -   compatible = "gpio-keys";
> -   autorepeat;
> -
> -   button-0 {
> -   label = "btn0";
> -   linux,code = ;
> -   gpios = <_1 12 (GPIO_ACTIVE_LOW | 
> GPIO_PULL_UP)>;
> -   wakeup-source;
> -   };
> -
> -   button-1 {
> -   label = "btn1";
> -   linux,code = ;
> -   gpios = <_1 13 (GPIO_ACTIVE_LOW | 
> GPIO_PULL_UP)>;
> -   wakeup-source;
> -   };
> -
> -   button-2 {
> -   label = "btn2";
> -   linux,code = ;
> -   gpios = <_1 14 (GPIO_ACTIVE_LOW | 
> GPIO_PULL_UP)>;
> -   wakeup-source;
> -   };
> -
> -   button-3 {
> -   label = "btn3";
> -   linux,code = ;
> -   gpios = <_1 15 (GPIO_ACTIVE_LOW | 
> GPIO_PULL_UP)>;
> -   wakeup-source;
> -   };
> -   };
> -
> -   bridge-connector {
> -   compatible = "hdmi-connector";
> -   type = "a";
> -
> -   port {
> -   hdmi_con: endpoint {
> -   remote-endpoint = <_out>;
> -   };
> -   };
> -   };
> -
> -   leds {
> -   compatible = "gpio-leds";
> -   pinctrl-names = "

Re: [PATCH v1] verdin-am62: move verdin am62 to OF_UPSTREAM

2024-04-03 Thread Sumit Garg
On Wed, 3 Apr 2024 at 12:45, Marcel Ziswiler  wrote:
>
> From: Marcel Ziswiler 
>
> Move verdin-am62 to OF_UPSTREAM:
> - handle the fact that dtbs now have a 'ti/' prefix
> - imply OF_UPSTREAM
> - remove redundant files from arch/arm/dts leaving only the
>   *-u-boot.dtsi files
> - update MAINTAINERS file
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  arch/arm/dts/Makefile |1 -
>  arch/arm/dts/k3-am62-verdin-dev.dtsi  |  240 ---
>  arch/arm/dts/k3-am62-verdin-wifi.dtsi |   45 -
>  arch/arm/dts/k3-am62-verdin.dtsi  | 1443 -
>  .../dts/k3-am625-verdin-wifi-dev-binman.dtsi  |2 +-
>  arch/arm/dts/k3-am625-verdin-wifi-dev.dts |   22 -
>  arch/arm/mach-k3/am62x/Kconfig|1 +
>  board/toradex/verdin-am62/MAINTAINERS |4 -
>  configs/verdin-am62_a53_defconfig |2 +-
>  9 files changed, 3 insertions(+), 1757 deletions(-)
>  delete mode 100644 arch/arm/dts/k3-am62-verdin-dev.dtsi
>  delete mode 100644 arch/arm/dts/k3-am62-verdin-wifi.dtsi
>  delete mode 100644 arch/arm/dts/k3-am62-verdin.dtsi
>  delete mode 100644 arch/arm/dts/k3-am625-verdin-wifi-dev.dts
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7b7788f7550..18fedc16740 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1416,7 +1416,6 @@ dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
>   k3-am625-r5-sk.dtb \
>   k3-am625-beagleplay.dtb \
>   k3-am625-r5-beagleplay.dtb \
> - k3-am625-verdin-wifi-dev.dtb \
>   k3-am625-verdin-r5.dtb \
>   k3-am625-phyboard-lyra-rdk.dtb \
>   k3-am625-r5-phycore-som-2gb.dtb
> diff --git a/arch/arm/dts/k3-am62-verdin-dev.dtsi 
> b/arch/arm/dts/k3-am62-verdin-dev.dtsi
> deleted file mode 100644
> index 6701cb8974b..000
> --- a/arch/arm/dts/k3-am62-verdin-dev.dtsi
> +++ /dev/null
> @@ -1,240 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> -/*
> - * Copyright 2023 Toradex
> - *
> - * Common dtsi for Verdin AM62 SoM on Development carrier board
> - *
> - * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
> - * 
> https://www.toradex.com/products/carrier-board/verdin-development-board-kit
> - */
> -
> -/ {
> -   sound {
> -   compatible = "simple-audio-card";
> -   simple-audio-card,bitclock-master = <_dai>;
> -   simple-audio-card,format = "i2s";
> -   simple-audio-card,frame-master = <_dai>;
> -   simple-audio-card,name = "verdin-nau8822";
> -   simple-audio-card,routing =
> -   "Headphones", "LHP",
> -   "Headphones", "RHP",
> -   "Speaker", "LSPK",
> -   "Speaker", "RSPK",
> -   "Line Out", "AUXOUT1",
> -   "Line Out", "AUXOUT2",
> -   "LAUX", "Line In",
> -   "RAUX", "Line In",
> -   "LMICP", "Mic In",
> -   "RMICP", "Mic In";
> -   simple-audio-card,widgets =
> -   "Headphones", "Headphones",
> -   "Line Out", "Line Out",
> -   "Speaker", "Speaker",
> -   "Microphone", "Mic In",
> -   "Line", "Line In";
> -
> -   codec_dai: simple-audio-card,codec {
> -   clocks = <_refclk1>;
> -   sound-dai = <_1a>;
> -   };
> -
> -   simple-audio-card,cpu {
> -   sound-dai = <>;
> -   };
> -   };
> -};
> -
> -/* Verdin ETHs */
> - {
> -   pinctrl-names = "default";
> -   pinctrl-0 = <_rgmii1>, <_rgmii2>;
> -   status = "okay";
> -};
> -
> -/* MDIO, shared by Verdin ETH_1 (On-module PHY) and Verdin ETH_2_RGMII */
> -_mdio {
> -   status = "okay";
> -
> -   cpsw3g_phy1: ethernet-phy@7 {
> -   compatible = "ethernet-phy-ieee802.3-c22";
> -   

Re: [PATCH v5 03/16] phy: qcom: Add SNPS femto v2 USB HS phy

2024-04-02 Thread Sumit Garg
On Tue, 2 Apr 2024 at 15:37, Caleb Connolly  wrote:
>
> Hi Sumit,
>
> On 01/04/2024 06:46, Sumit Garg wrote:
> > On Thu, 28 Mar 2024 at 23:29, Caleb Connolly  
> > wrote:
> >>
> >> From: Bhupesh Sharma 
> >>
> >> Some Qualcomm SoCs newer than SDM845 feature a so-called "7nm phy"
> >> driver, notable the SM8250 SoC which will gain U-Boot support in
> >> upcoming patches.
> >>
> >> Introduce a driver based on the Linux driver.
> >>
> >> Signed-off-by: Bhupesh Sharma 
> >> [code cleanup, align symbol names with Linux, switch to clk/reset_bulk 
> >> APIs]
> >> Signed-off-by: Caleb Connolly 
> >> ---
> >>   drivers/phy/qcom/Kconfig  |   8 ++
> >>   drivers/phy/qcom/Makefile |   1 +
> >>   drivers/phy/qcom/phy-qcom-snps-femto-v2.c | 207 
> >> ++
> >>   3 files changed, 216 insertions(+)
> >>
> ...
> >> diff --git a/drivers/phy/qcom/phy-qcom-snps-femto-v2.c 
> >> b/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
> >> new file mode 100644
> >> index ..58eb01972402
> >> --- /dev/null
> >> +++ b/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
> ...
> >> +static inline void qcom_snps_hsphy_write_mask(void __iomem *base, u32 
> >> offset,
> >> + u32 mask, u32 val)
> >> +{
> >> +   u32 reg;
> >> +
> >> +   reg = readl_relaxed(base + offset);
> >> +
> >> +   reg &= ~mask;
> >> +   reg |= val & mask;
> >> +   writel_relaxed(reg, base + offset);
> >> +
> >> +   /* Ensure above write is completed */
> >> +   readl_relaxed(base + offset);
> >
> > It looks like you have missed addressing comments related to this API.
> > Again, why do we need this special handling in U-Boot? Why not just
> > clrsetbits_le32()?
>
> I have tried to find more info about this, but from what I can tell it's
> important (my guess is that it's a weird bus arbitration thing with the
> QMP phy's).
>
> If I replace this with clrsetbits_le32() then my SM8250 board crashdumps
> while probing USB. So it is needed (and I'm wondering now if I ought to
> switch back to this for the dwc3 qcom glue as well).

Strange, probably it's due to some strict device memory ordering
rules. If you can add some reasoning in comments for this API then
feel free to add:

Acked-by: Sumit Garg 

-Sumit


Re: [PATCH 00/31] rockchip: rk3399: Sync DT with linux v6.8 and update defconfigs

2024-04-01 Thread Sumit Garg
On Mon, 1 Apr 2024 at 16:34, Jonas Karlman  wrote:
>
> On 2024-04-01 12:53, Sumit Garg wrote:
> > On Mon, 1 Apr 2024 at 15:31, Jonas Karlman  wrote:
> >>
> >> On 2024-04-01 11:45, Jonas Karlman wrote:
> >>> Hi Sumit,
> >>>
> >>> On 2024-04-01 10:52, Sumit Garg wrote:
> >>>> Hi Jonas,
> >>>>
> >>>> On Mon, 1 Apr 2024 at 01:59, Jonas Karlman  wrote:
> >>>>>
> >>>>> This series adds support for new clocks used in linux v6.8 device trees,
> >>>>> enables use of FIT signature check for checksum validation and fixes
> >>>>> loading FIT from SD-card when loading FIT from eMMC fails.
> >>>>>
> >>>>> After this series it should be possible to move RK3399 boards to use
> >>>>> OF_UPSTREAM in a future patch once dts/upstream move to a v6.8+ tag.
> >>>>>
> >>>>
> >>>> Thanks for putting this effort together. A switch to v6.8 tag for
> >>>> OF_UPSTREAM will happen as part of patch [1]. So if you want to save
> >>>> further effort then you can just rebase with a switch to OF_UPSTREAM
> >>>> once that patch [1] lands in next.
> >>>
> >>> Because this is a jump of device tree files from v5.14-rc1 to v6.8,
> >>> reviewability and being able to cherry-pick these changes to my
> >>> rk3xxx-2024.04 branch, I think it is much more appropriate to first sync
> >>> everything to v6.8 and then in a separate series move to OF_UPSTREAM.
> >>> Else it can be very hard to understand some of the changes that has been
> >>> and was needed to be made to u-boot.dtsi files.
> >>
> >> Also forgot to mention that these synced DT files still contains some
> >> minor modification in #include dtsi paths of files that is shared
> >> between rk3288 (armv7) and rk3399 (armv8),
> >
> > I can only see rockchip-u-boot.dtsi being shared which should be
> > handled automatically. Is there anything else I am missing here?
>
> The following is a diff of arch/arm/dts rk3399 DTs after this series
> compared to fully synced v6.8.

This is due to the different DTS directory structure within U-Boot.
With OF_UPSTREAM, these modifications aren't required anymore.

>
> Also the content of cros-ec-keyboard.dtsi was excluded in this sync
> because it initially caused compile issues.

I suppose that's due to missing #include
 for cros-ec-keyboard.dtsi. Once
you enable OF_UPSTREAM then let me know if you encounter such issues.

-Sumit

>
> diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
> index d90fe4d40d48..789fd0dcc88b 100644
> --- a/arch/arm/dts/rk3399-gru.dtsi
> +++ b/arch/arm/dts/rk3399-gru.dtsi
> @@ -684,8 +684,8 @@ ap_i2c_audio:  {
> status = "okay";
>  };
>
> -#include 
> -#include 
> +#include 
> +#include 
>
>   {
> /*
> diff --git a/arch/arm/dts/rk3399pro-rock-pi-n10.dts 
> b/arch/arm/dts/rk3399pro-rock-pi-n10.dts
> index bf026786fa92..c58fb7658d7a 100644
> --- a/arch/arm/dts/rk3399pro-rock-pi-n10.dts
> +++ b/arch/arm/dts/rk3399pro-rock-pi-n10.dts
> @@ -8,7 +8,7 @@
>  /dts-v1/;
>  #include "rk3399.dtsi"
>  #include "rk3399-opp.dtsi"
> -#include 
> +#include 
>  #include "rk3399pro-vmarc-som.dtsi"
>
>  / {
>
> Regards,
> Jonas
>
> >
> > -Sumit
>


Re: [PATCH 00/31] rockchip: rk3399: Sync DT with linux v6.8 and update defconfigs

2024-04-01 Thread Sumit Garg
On Mon, 1 Apr 2024 at 15:54, Jonas Karlman  wrote:
>
> On 2024-04-01 12:08, Sumit Garg wrote:
> > On Mon, 1 Apr 2024 at 15:15, Jonas Karlman  wrote:
> >>
> >> Hi Sumit,
> >>
> >> On 2024-04-01 10:52, Sumit Garg wrote:
> >>> Hi Jonas,
> >>>
> >>> On Mon, 1 Apr 2024 at 01:59, Jonas Karlman  wrote:
> >>>>
> >>>> This series adds support for new clocks used in linux v6.8 device trees,
> >>>> enables use of FIT signature check for checksum validation and fixes
> >>>> loading FIT from SD-card when loading FIT from eMMC fails.
> >>>>
> >>>> After this series it should be possible to move RK3399 boards to use
> >>>> OF_UPSTREAM in a future patch once dts/upstream move to a v6.8+ tag.
> >>>>
> >>>
> >>> Thanks for putting this effort together. A switch to v6.8 tag for
> >>> OF_UPSTREAM will happen as part of patch [1]. So if you want to save
> >>> further effort then you can just rebase with a switch to OF_UPSTREAM
> >>> once that patch [1] lands in next.
> >>
> >> Because this is a jump of device tree files from v5.14-rc1 to v6.8,
> >> reviewability and being able to cherry-pick these changes to my
> >> rk3xxx-2024.04 branch, I think it is much more appropriate to first sync
> >> everything to v6.8 and then in a separate series move to OF_UPSTREAM.
> >> Else it can be very hard to understand some of the changes that has been
> >> and was needed to be made to u-boot.dtsi files.
> >
> > That's fair given it's a long pending DT sync.
> >
> >>
> >> Reviewability is one of the shortcomings with a switch to OF_UPSTREAM.
> >
> > I suppose the reasoning behind this thinking can be that people are
> > used to reviewing DTs alongside driver changes. However, these patches
> > aren't actual DT changes but rather DT imports which IMHO is a
> > distraction for the reviewer. The actual DT can be looked into
> > dts/upstream/ directory while reviewing the changes.
>
> Things like following was easier to spot when reviewing DT syncs:
> - A property that U-Boot depends on gets removed, as in [1].

That seems to be due to DT bindings compliance check where DT bindings
are the ABI. Although it is unfortunate due to dependency on legacy
DT, now we have the same dtbs_check in U-Boot too:

$ make _defconfig
$ make -j`nproc` dtbs_check

This shall keep U-Boot in compliance with DT bindings and help avoid
such dependencies.

> - Some DT changes can break changes that has been made to u-boot.dtsi
>   files, e.g. a symbol to a node is no longer available in upstream but
>   referenced in u-boot.dtsi files (happened in this series).

Node names aren't a DT ABI so we should expect some changes there.

> - Changes in DT may require a workaround in a u-boot.dtsi file.
> - u-boot.dtsi contains workarounds that has not yet been upstream but
>   can be removed in a future DT sync.

Agree, we should try to minimize modifications via u-boot.dtsi
especially all the bootph* related properties should be posted
upstream.

> - Driver incompatibilities due to initial driver imported from vendor
>   ended up not fully compatible with upstream linux driver / dt-binding.

Given all the above and the big jump in DT sync for Rockchip
platforms, I am fine with the transition being step by step.

-Sumit

>
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4d08b19629495b29601991d09d07865694c25199
>


Re: [PATCH 00/31] rockchip: rk3399: Sync DT with linux v6.8 and update defconfigs

2024-04-01 Thread Sumit Garg
On Mon, 1 Apr 2024 at 15:31, Jonas Karlman  wrote:
>
> On 2024-04-01 11:45, Jonas Karlman wrote:
> > Hi Sumit,
> >
> > On 2024-04-01 10:52, Sumit Garg wrote:
> >> Hi Jonas,
> >>
> >> On Mon, 1 Apr 2024 at 01:59, Jonas Karlman  wrote:
> >>>
> >>> This series adds support for new clocks used in linux v6.8 device trees,
> >>> enables use of FIT signature check for checksum validation and fixes
> >>> loading FIT from SD-card when loading FIT from eMMC fails.
> >>>
> >>> After this series it should be possible to move RK3399 boards to use
> >>> OF_UPSTREAM in a future patch once dts/upstream move to a v6.8+ tag.
> >>>
> >>
> >> Thanks for putting this effort together. A switch to v6.8 tag for
> >> OF_UPSTREAM will happen as part of patch [1]. So if you want to save
> >> further effort then you can just rebase with a switch to OF_UPSTREAM
> >> once that patch [1] lands in next.
> >
> > Because this is a jump of device tree files from v5.14-rc1 to v6.8,
> > reviewability and being able to cherry-pick these changes to my
> > rk3xxx-2024.04 branch, I think it is much more appropriate to first sync
> > everything to v6.8 and then in a separate series move to OF_UPSTREAM.
> > Else it can be very hard to understand some of the changes that has been
> > and was needed to be made to u-boot.dtsi files.
>
> Also forgot to mention that these synced DT files still contains some
> minor modification in #include dtsi paths of files that is shared
> between rk3288 (armv7) and rk3399 (armv8),

I can only see rockchip-u-boot.dtsi being shared which should be
handled automatically. Is there anything else I am missing here?

-Sumit


Re: [PATCH 00/31] rockchip: rk3399: Sync DT with linux v6.8 and update defconfigs

2024-04-01 Thread Sumit Garg
On Mon, 1 Apr 2024 at 15:15, Jonas Karlman  wrote:
>
> Hi Sumit,
>
> On 2024-04-01 10:52, Sumit Garg wrote:
> > Hi Jonas,
> >
> > On Mon, 1 Apr 2024 at 01:59, Jonas Karlman  wrote:
> >>
> >> This series adds support for new clocks used in linux v6.8 device trees,
> >> enables use of FIT signature check for checksum validation and fixes
> >> loading FIT from SD-card when loading FIT from eMMC fails.
> >>
> >> After this series it should be possible to move RK3399 boards to use
> >> OF_UPSTREAM in a future patch once dts/upstream move to a v6.8+ tag.
> >>
> >
> > Thanks for putting this effort together. A switch to v6.8 tag for
> > OF_UPSTREAM will happen as part of patch [1]. So if you want to save
> > further effort then you can just rebase with a switch to OF_UPSTREAM
> > once that patch [1] lands in next.
>
> Because this is a jump of device tree files from v5.14-rc1 to v6.8,
> reviewability and being able to cherry-pick these changes to my
> rk3xxx-2024.04 branch, I think it is much more appropriate to first sync
> everything to v6.8 and then in a separate series move to OF_UPSTREAM.
> Else it can be very hard to understand some of the changes that has been
> and was needed to be made to u-boot.dtsi files.

That's fair given it's a long pending DT sync.

>
> Reviewability is one of the shortcomings with a switch to OF_UPSTREAM.

I suppose the reasoning behind this thinking can be that people are
used to reviewing DTs alongside driver changes. However, these patches
aren't actual DT changes but rather DT imports which IMHO is a
distraction for the reviewer. The actual DT can be looked into
dts/upstream/ directory while reviewing the changes.

-Sumit

>
> Regards,
> Jonas
>
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2024-March/549611.html
> >
> > -Sumit
> >
> >> I have runtime tested this series on following devices:
> >> - 96boards Rock960
> >> - Khadas Edge Captain
> >> - Pine64 PineBook Pro
> >> - Pine64 RockPro64
> >> - Radxa ROCK 4C+
> >> - Radxa ROCK 4SE
> >> - Radxa ROCK Pi 4A
> >> - Radxa ROCK Pi 4B+
> >>
> >> This series depends on the following series:
> >> - Enable booting from SPI flash on ROCK Pi 4 [1]
> >> - rockchip: spl: Cache boot source id for later use [2]
> >>
> >> A copy of this series and all its depends can be found at [3]
> >>
> >> [1] https://patchwork.ozlabs.org/cover/1912469/
> >> [2] https://patchwork.ozlabs.org/cover/1915071/
> >> [3] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3399-dt-sync-v1
> >>
> >> Jonas Karlman (31):
> >>   rockchip: rk3399-gru: Fix max SPL size on bob and kevin
> >>   rockchip: rk3399-ficus: Enable TPL and use common bss and stack addr
> >>   rockchip: rk3399: Sort imply statements alphabetically
> >>   rockchip: rk3399: Enable ARMv8 crypto and FIT checksum validation
> >>   rockchip: rk3399: Enable random generator on all boards
> >>   rockchip: rk3399: Imply support for GbE PHY
> >>   rockchip: rk3399: Enable DT overlay support on all boards
> >>   rockchip: rk3399: Remove use of xPL_MISC_DRIVERS options
> >>   rockchip: rk3399: Add a default spl-boot-order prop
> >>   rockchip: rk3399: Fix loading FIT from SD-card when booting from eMMC
> >>   clk: rockchip: rk3399: Rename SCLK_DDRCLK to SCLK_DDRC
> >>   clk: rockchip: rk3399: Add dummy support for ACLK_VDU clock
> >>   clk: rockchip: rk3399: Add dummy support for SCLK_PCIEPHY_REF clock
> >>   clk: rockchip: rk3399: Add SCLK_USB3OTGx_REF support
> >>   rockchip: rk3399: Sync soc device tree from linux v6.8
> >>   rockchip: rk3399-gru: Sync device tree from linux v6.8
> >>   rockchip: rk3399-puma: Sync DT from linux v6.8
> >>   rockchip: rk3399-rock-pi-n10: Sync device tree from linux v6.8
> >>   rockchip: rk3399-eaidk-610: Sync device tree from linux v6.8
> >>   rockchip: rk3399-leez: Sync device tree from linux v6.8
> >>   rockchip: rk3399-evb: Sync device tree from linux v6.8
> >>   rockchip: rk3399-firefly: Sync device tree from linux v6.8
> >>   rockchip: rk3399-orangepi: Sync device tree from linux v6.8
> >>   rockchip: rk3399-roc-pc: Sync device tree from linux v6.8
> >>   rockchip: rk3399-nanopi-4: Sync device tree from linux v6.8
> >>   rockchip: rk3399-rock960: Sync device tree from linux v6.8
> >>   rockchip: rk3399-khadas: Sync device tree from linux v6.8
> >>   rockchip: rk3399-rock-pi-4: Sync device tree from linux v6.8
> >>   ro

Re: [PATCH 11/31] clk: rockchip: rk3399: Rename SCLK_DDRCLK to SCLK_DDRC

2024-04-01 Thread Sumit Garg
On Mon, 1 Apr 2024 at 02:01, Jonas Karlman  wrote:
>
> Sync rk3399-cru.h with one from linux v6.2+ and fix use of the
> SCLK_DDRCLK name that was only used by U-Boot.
>
> Signed-off-by: Jonas Karlman 
> ---
>  arch/arm/dts/rk3399-u-boot.dtsi|  2 +-
>  drivers/clk/rockchip/clk_rk3399.c  |  2 +-
>  include/dt-bindings/clock/rk3399-cru.h | 30 ++

You shouldn't need to sync this header but rather just drop it which
will lead to ./dts/upstream/include/dt-bindings/clock/rk3399-cru.h
being included automatically. Similarly you should be able to drop all
other duplicate headers as demonstrated by this [1] patch-set.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=399954

-Sumit

>  3 files changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 69e6b808a69b..adb64d17e040 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -44,7 +44,7 @@
> compatible = "rockchip,rk3399-dmc";
> devfreq-events = <>;
> interrupts = ;
> -   clocks = < SCLK_DDRCLK>;
> +   clocks = < SCLK_DDRC>;
> clock-names = "dmc_clk";
> reg = <0x0 0xffa8 0x0 0x0800
>0x0 0xffa80800 0x0 0x1800
> diff --git a/drivers/clk/rockchip/clk_rk3399.c 
> b/drivers/clk/rockchip/clk_rk3399.c
> index 80f65a237e8e..f0ce54067f8c 100644
> --- a/drivers/clk/rockchip/clk_rk3399.c
> +++ b/drivers/clk/rockchip/clk_rk3399.c
> @@ -1049,7 +1049,7 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
> rate)
>  * return 0 to satisfy clk_set_defaults during device probe.
>  */
> return 0;
> -   case SCLK_DDRCLK:
> +   case SCLK_DDRC:
> ret = rk3399_ddr_set_clk(priv->cru, rate);
> break;
> case PCLK_EFUSE1024NS:
> diff --git a/include/dt-bindings/clock/rk3399-cru.h 
> b/include/dt-bindings/clock/rk3399-cru.h
> index 211faf8fa891..39169d94a44e 100644
> --- a/include/dt-bindings/clock/rk3399-cru.h
> +++ b/include/dt-bindings/clock/rk3399-cru.h
> @@ -1,6 +1,7 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>  /*
>   * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
> + * Author: Xing Zheng 
>   */
>
>  #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
> @@ -121,16 +122,17 @@
>  #define SCLK_DPHY_RX0_CFG  165
>  #define SCLK_RMII_SRC  166
>  #define SCLK_PCIEPHY_REF100M   167
> -#define SCLK_USBPHY0_480M_SRC  168
> -#define SCLK_USBPHY1_480M_SRC  169
> -#define SCLK_DDRCLK170
> -#define SCLK_TESTOUT2  171
> +#define SCLK_DDRC  168
> +#define SCLK_TESTCLKOUT1   169
> +#define SCLK_TESTCLKOUT2   170
>
>  #define DCLK_VOP0  180
>  #define DCLK_VOP1  181
>  #define DCLK_VOP0_DIV  182
>  #define DCLK_VOP1_DIV  183
>  #define DCLK_M0_PERILP 184
> +#define DCLK_VOP0_FRAC 185
> +#define DCLK_VOP1_FRAC 186
>
>  #define FCLK_CM0S  190
>
> @@ -545,8 +547,8 @@
>  #define SRST_H_PERILP0 171
>  #define SRST_H_PERILP0_NOC 172
>  #define SRST_ROM   173
> -#define SRST_CRYPTO_S  174
> -#define SRST_CRYPTO_M  175
> +#define SRST_CRYPTO0_S 174
> +#define SRST_CRYPTO0_M 175
>
>  /* cru_softrst_con11 */
>  #define SRST_P_DCF 176
> @@ -554,7 +556,7 @@
>  #define SRST_CM0S  178
>  #define SRST_CM0S_DBG  179
>  #define SRST_CM0S_PO   180
> -#define SRST_CRYPTO181
> +#define SRST_CRYPTO0   181
>  #define SRST_P_PERILP1_SGRF182
>  #define SRST_P_PERILP1_GRF 183
>  #define SRST_CRYPTO1_S 184
> @@ -592,13 +594,13 @@
>  #define SRST_P_SPI0214
>  #define SRST_P_SPI1215
>  #define SRST_P_SPI2216
> -#define SRST_P_SPI4217
> -#define SRST_P_SPI5218
> +#define SRST_P_SPI3217
> +#define SRST_P_SPI4218
>  #define SRST_SPI0  219
>  #define SRST_SPI1  220
>  #define SRST_SPI2  221
> -#define SRST_SPI4  222
> -#define SRST_SPI5  223
> +#define SRST_SPI3  222
> +#define SRST_SPI4  223
>
>  /* cru_softrst_con14 */
>  #define SRST_I2S0_8CH  224
> @@ -720,8 +722,8 @@
>  #define SRST_H_CM0S_NOC3
>  #define SRST_DBG_CM0S  4
>  #define 

Re: [PATCH 00/31] rockchip: rk3399: Sync DT with linux v6.8 and update defconfigs

2024-04-01 Thread Sumit Garg
Hi Jonas,

On Mon, 1 Apr 2024 at 01:59, Jonas Karlman  wrote:
>
> This series adds support for new clocks used in linux v6.8 device trees,
> enables use of FIT signature check for checksum validation and fixes
> loading FIT from SD-card when loading FIT from eMMC fails.
>
> After this series it should be possible to move RK3399 boards to use
> OF_UPSTREAM in a future patch once dts/upstream move to a v6.8+ tag.
>

Thanks for putting this effort together. A switch to v6.8 tag for
OF_UPSTREAM will happen as part of patch [1]. So if you want to save
further effort then you can just rebase with a switch to OF_UPSTREAM
once that patch [1] lands in next.

[1] https://lists.denx.de/pipermail/u-boot/2024-March/549611.html

-Sumit

> I have runtime tested this series on following devices:
> - 96boards Rock960
> - Khadas Edge Captain
> - Pine64 PineBook Pro
> - Pine64 RockPro64
> - Radxa ROCK 4C+
> - Radxa ROCK 4SE
> - Radxa ROCK Pi 4A
> - Radxa ROCK Pi 4B+
>
> This series depends on the following series:
> - Enable booting from SPI flash on ROCK Pi 4 [1]
> - rockchip: spl: Cache boot source id for later use [2]
>
> A copy of this series and all its depends can be found at [3]
>
> [1] https://patchwork.ozlabs.org/cover/1912469/
> [2] https://patchwork.ozlabs.org/cover/1915071/
> [3] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3399-dt-sync-v1
>
> Jonas Karlman (31):
>   rockchip: rk3399-gru: Fix max SPL size on bob and kevin
>   rockchip: rk3399-ficus: Enable TPL and use common bss and stack addr
>   rockchip: rk3399: Sort imply statements alphabetically
>   rockchip: rk3399: Enable ARMv8 crypto and FIT checksum validation
>   rockchip: rk3399: Enable random generator on all boards
>   rockchip: rk3399: Imply support for GbE PHY
>   rockchip: rk3399: Enable DT overlay support on all boards
>   rockchip: rk3399: Remove use of xPL_MISC_DRIVERS options
>   rockchip: rk3399: Add a default spl-boot-order prop
>   rockchip: rk3399: Fix loading FIT from SD-card when booting from eMMC
>   clk: rockchip: rk3399: Rename SCLK_DDRCLK to SCLK_DDRC
>   clk: rockchip: rk3399: Add dummy support for ACLK_VDU clock
>   clk: rockchip: rk3399: Add dummy support for SCLK_PCIEPHY_REF clock
>   clk: rockchip: rk3399: Add SCLK_USB3OTGx_REF support
>   rockchip: rk3399: Sync soc device tree from linux v6.8
>   rockchip: rk3399-gru: Sync device tree from linux v6.8
>   rockchip: rk3399-puma: Sync DT from linux v6.8
>   rockchip: rk3399-rock-pi-n10: Sync device tree from linux v6.8
>   rockchip: rk3399-eaidk-610: Sync device tree from linux v6.8
>   rockchip: rk3399-leez: Sync device tree from linux v6.8
>   rockchip: rk3399-evb: Sync device tree from linux v6.8
>   rockchip: rk3399-firefly: Sync device tree from linux v6.8
>   rockchip: rk3399-orangepi: Sync device tree from linux v6.8
>   rockchip: rk3399-roc-pc: Sync device tree from linux v6.8
>   rockchip: rk3399-nanopi-4: Sync device tree from linux v6.8
>   rockchip: rk3399-rock960: Sync device tree from linux v6.8
>   rockchip: rk3399-khadas: Sync device tree from linux v6.8
>   rockchip: rk3399-rock-pi-4: Sync device tree from linux v6.8
>   rockchip: rk3399-rockpro64: Sync device tree from linux v6.8
>   rockchip: rk3399-pinebook-pro: Sync device tree from linux v6.8
>   rockchip: rk3399-pinephone-pro: Sync device tree from linux v6.8
>
>  arch/arm/dts/rk3288-vmarc-som.dtsi|  48 +++
>  arch/arm/dts/rk3399-eaidk-610-u-boot.dtsi |   1 -
>  arch/arm/dts/rk3399-eaidk-610.dts |   3 +-
>  arch/arm/dts/rk3399-evb-u-boot.dtsi   |  13 +-
>  arch/arm/dts/rk3399-evb.dts   |   3 +-
>  arch/arm/dts/rk3399-ficus-u-boot.dtsi |  10 +-
>  arch/arm/dts/rk3399-ficus.dts |   4 +
>  arch/arm/dts/rk3399-firefly-u-boot.dtsi   |   6 -
>  arch/arm/dts/rk3399-firefly.dts   |  17 +-
>  arch/arm/dts/rk3399-gru-bob.dts   |   8 +-
>  arch/arm/dts/rk3399-gru-chromebook.dtsi   | 200 +++-
>  arch/arm/dts/rk3399-gru-kevin.dts |   3 +-
>  arch/arm/dts/rk3399-gru-u-boot.dtsi   |  34 ++-
>  arch/arm/dts/rk3399-gru.dtsi  |  52 +++-
>  arch/arm/dts/rk3399-khadas-edge-captain.dts   |   4 +
>  arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi   |   7 +-
>  arch/arm/dts/rk3399-khadas-edge-v.dts |   4 +
>  arch/arm/dts/rk3399-khadas-edge.dtsi  |  10 +-
>  arch/arm/dts/rk3399-leez-p710-u-boot.dtsi |   6 -
>  arch/arm/dts/rk3399-leez-p710.dts |   8 +-
>  arch/arm/dts/rk3399-nanopc-t4.dts |   2 +-
>  arch/arm/dts/rk3399-nanopi-m4-2gb.dts |  55 +---
>  arch/arm/dts/rk3399-nanopi-m4b.dts|   2 +-
>  arch/arm/dts/rk3399-nanopi-r4s.dts|   4 +-
>  arch/arm/dts/rk3399-nanopi4-u-boot.dtsi   |  18 +-
>  arch/arm/dts/rk3399-nanopi4.dtsi  |   7 +-
>  arch/arm/dts/rk3399-op1-opp.dtsi  |  31 +-
>  arch/arm/dts/rk3399-opp.dtsi  |   6 +-
>  

Re: [PATCH v5 15/16] qcom_defconfig: enable USB

2024-03-31 Thread Sumit Garg
On Thu, 28 Mar 2024 at 23:29, Caleb Connolly  wrote:
>
> Enable support for the DWC3 USB controller and required dependencies for
> Qualcomm boards, specifically the DB845c:
> * IOMMU / SMMU
> * USB high-speed PHYs
> * Mass storage and ACM gadgets
>
> Signed-off-by: Caleb Connolly 
> ---
>  configs/qcom_defconfig | 52 
> --
>  1 file changed, 29 insertions(+), 23 deletions(-)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> index 8c4402e8f780..1abb57345ff1 100644
> --- a/configs/qcom_defconfig
> +++ b/configs/qcom_defconfig
> @@ -17,10 +17,16 @@ CONFIG_LOG_MAX_LEVEL=9
>  CONFIG_LOG_DEFAULT_LEVEL=4
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_CMD_BOOTMENU=y
> +CONFIG_CMD_EEPROM=y
> +CONFIG_SYS_I2C_EEPROM_BUS=2
> +CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
> +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5
> +# CONFIG_CMD_BIND is not set
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_GPIO=y
> +CONFIG_CMD_I2C=y
>  CONFIG_CMD_MMC=y
>  CONFIG_CMD_UFS=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_CAT=y
> @@ -32,20 +38,39 @@ CONFIG_CLK=y
>  CONFIG_CLK_QCOM_QCS404=y
>  CONFIG_CLK_QCOM_SDM845=y
>  CONFIG_MSM_GPIO=y
>  CONFIG_QCOM_PMIC_GPIO=y
> +CONFIG_DM_I2C=y
> +CONFIG_SYS_I2C_QUP=y
> +CONFIG_I2C_MUX=y
>  CONFIG_DM_KEYBOARD=y
>  CONFIG_BUTTON_KEYBOARD=y
> +CONFIG_IOMMU=y
> +CONFIG_QCOM_HYP_SMMU=y
> +CONFIG_MISC=y
> +CONFIG_NVMEM=y
> +CONFIG_I2C_EEPROM=y
>  CONFIG_MMC_HS200_SUPPORT=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_ADMA=y
>  CONFIG_MMC_SDHCI_MSM=y
> +CONFIG_PHY_MICREL=y
> +CONFIG_PHY_MICREL_KSZ90X1=y
> +CONFIG_DM_MDIO=y
> +CONFIG_DM_ETH_PHY=y
> +CONFIG_DWC_ETH_QOS=y
> +CONFIG_DWC_ETH_QOS_QCOM=y
> +CONFIG_RGMII=y
>  CONFIG_PHY=y
> +CONFIG_PHY_QCOM_QUSB2=y
> +CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2=y
>  CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_QCOM_QCS404=y
>  CONFIG_PINCTRL_QCOM_SDM845=y
>  CONFIG_DM_PMIC=y
>  CONFIG_PMIC_QCOM=y
> +CONFIG_DM_REGULATOR=y
> +CONFIG_DM_REGULATOR_FIXED=y
>  CONFIG_SCSI=y
>  CONFIG_MSM_SERIAL=y
>  CONFIG_MSM_GENI_SERIAL=y
>  CONFIG_SPMI_MSM=y
> @@ -54,8 +79,12 @@ CONFIG_SYSINFO_SMBIOS=y
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_DWC3=y
> +CONFIG_USB_DWC3_GENERIC=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_USB_FUNCTION_MASS_STORAGE=y
>  CONFIG_UFS=y
>  CONFIG_VIDEO=y
>  # CONFIG_VIDEO_FONT_8X16 is not set
>  CONFIG_VIDEO_FONT_16X32=y
> @@ -64,27 +93,4 @@ CONFIG_NO_FB_CLEAR=y
>  CONFIG_VIDEO_SIMPLE=y
>  CONFIG_HEXDUMP=y
>  # CONFIG_GENERATE_SMBIOS_TABLE is not set
>  CONFIG_LMB_MAX_REGIONS=64
> -CONFIG_CMD_DHCP=y
> -CONFIG_CMD_EEPROM=y
> -CONFIG_CMD_I2C=y
> -CONFIG_CMD_PING=y
> -CONFIG_DM_ETH=y
> -CONFIG_DM_ETH_PHY=y
> -CONFIG_DM_MDIO=y
> -CONFIG_DWC_ETH_QOS=y
> -CONFIG_DWC_ETH_QOS_QCOM=y
> -CONFIG_RGMII=y
> -CONFIG_PHY_MICREL=y
> -CONFIG_PHY_MICREL_KSZ90X1=y
> -CONFIG_MISC=y
> -CONFIG_NVMEM=y
> -CONFIG_DM_I2C=y
> -CONFIG_I2C_SUPPORT=y
> -CONFIG_I2C_MUX=y
> -CONFIG_I2C_EEPROM=y
> -CONFIG_SYS_I2C=y
> -CONFIG_SYS_I2C_QUP=y
> -CONFIG_SYS_I2C_EEPROM_BUS=2
> -CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
> -CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5
>
> --
> 2.44.0
>


Re: [PATCH v5 14/16] qcom_defconfig: enable livetree

2024-03-31 Thread Sumit Garg
On Thu, 28 Mar 2024 at 23:29, Caleb Connolly  wrote:
>
> Qualcomm FDTs are on the larger size, and with the addition of DT
> modifications during board_init() it makes sense to enable OF_LIVE
> globally. The cost of building the tree should be offset by the
> increased efficiency at which we can walk it.
>
> Some rough measurements with CONFIG_BOOTSTAGE suggests that this might
> add 0.1-0.2ms to the boot-to-console time. However the reset-to-reset
> timer difference is in the range of 0.5ms so this could just be noise.
>
> Suffice to say, no significant slow down.
>
> Reviewed-by: Neil Armstrong 
> Signed-off-by: Caleb Connolly 
> ---
>  configs/qcom_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig
> index cbc612b44bd9..8c4402e8f780 100644
> --- a/configs/qcom_defconfig
> +++ b/configs/qcom_defconfig
> @@ -25,8 +25,9 @@ CONFIG_CMD_UFS=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_CAT=y
>  CONFIG_CMD_BMP=y
>  CONFIG_CMD_LOG=y
> +CONFIG_OF_LIVE=y
>  CONFIG_BUTTON_QCOM_PMIC=y
>  CONFIG_CLK=y
>  CONFIG_CLK_QCOM_QCS404=y
>  CONFIG_CLK_QCOM_SDM845=y
>
> --
> 2.44.0
>


Re: [PATCH v5 13/16] dts: sdm845-db845c: add u-boot fixups

2024-03-31 Thread Sumit Garg
On Thu, 28 Mar 2024 at 23:29, Caleb Connolly  wrote:
>
> The USB VBUS supply for the type-A port is enabled via a GPIO regulator.
> This is incorrectly modelled in Linux where only the PCIe dependency is
> expressed. The correct way to handle this will be through a
> usb-connector node, but for now we'll just mark the regulator as
> always-on so that it will be enabled automatically during boot.
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/dts/sdm845-db845c-u-boot.dtsi | 9 +
>  1 file changed, 9 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/dts/sdm845-db845c-u-boot.dtsi 
> b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
> new file mode 100644
> index ..906f9faa5451
> --- /dev/null
> +++ b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/* Needed for Linux to boot from USB, otherwise if PCIe driver is not in 
> initramfs
> + * the VBUS supply will never get turned on.
> + * 
> https://lore.kernel.org/linux-arm-msm/20240320122515.3243711-1-caleb.conno...@linaro.org/
> + */
> +_3p3v_dual {
> +   regulator-always-on;
> +};
>
> --
> 2.44.0
>


Re: [PATCH v5 12/16] mach-snapdragon: call regulators_enable_boot_on()

2024-03-31 Thread Sumit Garg
On Thu, 28 Mar 2024 at 23:29, Caleb Connolly  wrote:
>
> Make sure we power on any boot-on or always-on regulators. These are
> used for peripherals like USB on some platforms.
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/mach-snapdragon/board.c | 2 ++
>  1 file changed, 2 insertions(+)
>

Reviewed-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/mach-snapdragon/board.c 
> b/arch/arm/mach-snapdragon/board.c
> index 65e4c61e866a..3d5994c87886 100644
> --- a/arch/arm/mach-snapdragon/board.c
> +++ b/arch/arm/mach-snapdragon/board.c
> @@ -15,8 +15,9 @@
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> @@ -160,8 +161,9 @@ void __weak qcom_board_init(void)
>  }
>
>  int board_init(void)
>  {
> +   regulators_enable_boot_on(false);
> show_psci_version();
> qcom_of_fixup_nodes();
> qcom_board_init();
> return 0;
>
> --
> 2.44.0
>


Re: [PATCH v5 11/16] mach-snapdragon: fixup power-domains

2024-03-31 Thread Sumit Garg
On Thu, 28 Mar 2024 at 23:29, Caleb Connolly  wrote:
>
> We don't support the RPM(h)PD power domains in U-Boot, and we don't need
> to - the necessary resources are on, and we aren't going to enter any
> low power modes.
>
> We could try using a no-op device, but this requires adding a compatible
> for every platform, and just pollutes the driver model. So instead let's
> just remove every "power-domains" property that references the RPM(h)pd
> power controller. This takes <1ms as we're using OF_LIVE.
>
> Of note, this only applies to drivers which are loading post-relocation.
> Drivers loaded pre-reloc that reference the rpm(h)pd still need
> DM_FLAG_DEFAULT_PD_CTRL_OFF in their flags.
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/mach-snapdragon/of_fixup.c | 32 ++++
>  1 file changed, 32 insertions(+)
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/mach-snapdragon/of_fixup.c 
> b/arch/arm/mach-snapdragon/of_fixup.c
> index 4fdfed2dff16..3f7ac227bd09 100644
> --- a/arch/arm/mach-snapdragon/of_fixup.c
> +++ b/arch/arm/mach-snapdragon/of_fixup.c
> @@ -21,8 +21,9 @@
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  /* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
>   * USB controllers. Rather than requiring source level DT changes, we fix up
> @@ -109,8 +110,38 @@ static void fixup_usb_nodes(void)
> log_warning("Failed to fixup node %s: %d\n", 
> glue_np->name, ret);
> }
>  }
>
> +/* Remove all references to the rpmhpd device */
> +static void fixup_power_domains(void)
> +{
> +   struct device_node *pd = NULL, *np = NULL;
> +   struct property *prop;
> +   const __be32 *val;
> +
> +   /* All Qualcomm platforms name the rpm(h)pd "power-controller" */
> +   for_each_of_allnodes(pd) {
> +   if (pd->name && !strcmp("power-controller", pd->name))
> +   break;
> +   }
> +
> +   /* Sanity check that this is indeed a power domain controller */
> +   if (!of_find_property(pd, "#power-domain-cells", NULL)) {
> +   log_err("Found power-controller but it doesn't have 
> #power-domain-cells\n");
> +   return;
> +   }
> +
> +   /* Remove all references to the power domain controller */
> +   for_each_of_allnodes(np) {
> +   if (!(prop = of_find_property(np, "power-domains", NULL)))
> +   continue;
> +
> +   val = prop->value;
> +   if (val[0] == cpu_to_fdt32(pd->phandle))
> +   of_remove_property(np, prop);
> +   }
> +}
> +
>  #define time_call(func, ...) \
> do { \
> u64 start = timer_get_us(); \
> func(__VA_ARGS__); \
> @@ -119,5 +150,6 @@ static void fixup_usb_nodes(void)
>
>  void qcom_of_fixup_nodes(void)
>  {
> time_call(fixup_usb_nodes);
> +   time_call(fixup_power_domains);
>  }
>
> --
> 2.44.0
>


Re: [PATCH v5 10/16] mach-snapdragon: fixup USB nodes

2024-03-31 Thread Sumit Garg
On Thu, 28 Mar 2024 at 23:29, Caleb Connolly  wrote:
>
> We don't support USB super-speed in U-Boot yet, we lack the SS PHY
> drivers, however from my testing even with a PHY driver there seem to be
> other issues when talking to super-speed peripherals.
>
> In pursuit of maintaining upstream DT compatibility, and simplifying
> porting for new devices, let's implement the DT fixups necessary to
> configure USB in high-speed only mode at runtime. The pattern is
> identical for all Qualcomm boards that use the Synaptics DWC3
> controller:
>
> * Add an additional property on the Qualcomm wrapper node
> * Remove the super-speed phy phandle and phy-name entries.
>
> Signed-off-by: Caleb Connolly 
> ---
>  arch/arm/mach-snapdragon/Makefile|   1 +
>  arch/arm/mach-snapdragon/board.c |   3 +
>  arch/arm/mach-snapdragon/of_fixup.c  | 123 
> +++
>  arch/arm/mach-snapdragon/qcom-priv.h |  20 ++
>  4 files changed, 147 insertions(+)
>

Acked-by: Sumit Garg 

-Sumit

> diff --git a/arch/arm/mach-snapdragon/Makefile 
> b/arch/arm/mach-snapdragon/Makefile
> index 857171e593da..7a4495c8108f 100644
> --- a/arch/arm/mach-snapdragon/Makefile
> +++ b/arch/arm/mach-snapdragon/Makefile
> @@ -2,4 +2,5 @@
>  #
>  # (C) Copyright 2015 Mateusz Kulikowski 
>
>  obj-y += board.o
> +obj-$(CONFIG_OF_LIVE) += of_fixup.o
> diff --git a/arch/arm/mach-snapdragon/board.c 
> b/arch/arm/mach-snapdragon/board.c
> index 6f762fc948bf..65e4c61e866a 100644
> --- a/arch/arm/mach-snapdragon/board.c
> +++ b/arch/arm/mach-snapdragon/board.c
> @@ -27,8 +27,10 @@
>  #include 
>  #include 
>  #include 
>
> +#include "qcom-priv.h"
> +
>  DECLARE_GLOBAL_DATA_PTR;
>
>  static struct mm_region rbx_mem_map[CONFIG_NR_DRAM_BANKS + 2] = { { 0 } };
>
> @@ -159,8 +161,9 @@ void __weak qcom_board_init(void)
>
>  int board_init(void)
>  {
> show_psci_version();
> +   qcom_of_fixup_nodes();
> qcom_board_init();
> return 0;
>  }
>
> diff --git a/arch/arm/mach-snapdragon/of_fixup.c 
> b/arch/arm/mach-snapdragon/of_fixup.c
> new file mode 100644
> index ..4fdfed2dff16
> --- /dev/null
> +++ b/arch/arm/mach-snapdragon/of_fixup.c
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * OF_LIVE devicetree fixup.
> + *
> + * This file implements runtime fixups for Qualcomm DT to improve
> + * compatibility with U-Boot. This includes adjusting the USB nodes
> + * to only use USB high-speed, as well as remapping volume buttons
> + * to behave as up/down for navigating U-Boot.
> + *
> + * We use OF_LIVE for this rather than early FDT fixup for a couple
> + * of reasons: it has a much nicer API, is most likely more efficient,
> + * and our changes are only applied to U-Boot. This allows us to use a
> + * DT designed for Linux, run U-Boot with a modified version, and then
> + * boot Linux with the original FDT.
> + *
> + * Copyright (c) 2024 Linaro Ltd.
> + *   Author: Caleb Connolly 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
> + * USB controllers. Rather than requiring source level DT changes, we fix up
> + * DT here. This improves compatibility with upstream DT and simplifies the
> + * porting process for new devices.
> + */
> +static int fixup_qcom_dwc3(struct device_node *glue_np)
> +{
> +   struct device_node *dwc3;
> +   int ret, len, hsphy_idx = 1;
> +   const __be32 *phandles;
> +   const char *second_phy_name;
> +
> +   debug("Fixing up %s\n", glue_np->name);
> +
> +   /* Tell the glue driver to configure the wrapper for high-speed only 
> operation */
> +   ret = of_write_prop(glue_np, "qcom,select-utmi-as-pipe-clk", 0, NULL);
> +   if (ret) {
> +   log_err("Failed to add property 
> 'qcom,select-utmi-as-pipe-clk': %d\n", ret);
> +   return ret;
> +   }
> +
> +   /* Find the DWC3 node itself */
> +   dwc3 = of_find_compatible_node(glue_np, NULL, "snps,dwc3");
> +   if (!dwc3) {
> +   log_err("Failed to find dwc3 node\n");
> +   return -ENOENT;
> +   }
> +
> +   phandles = of_get_property(dwc3, "phys", );
> +   len /= sizeof(*phandles);
> +   if (len == 1) {
> +   log_debug("Only one phy, not a superspeed controller\n");
> +   return 0;
> +   }
> +
> +   /* Figure out if the superspeed phy is present and if so then which 
> phy 

Re: [PATCH v5 03/16] phy: qcom: Add SNPS femto v2 USB HS phy

2024-03-31 Thread Sumit Garg
On Thu, 28 Mar 2024 at 23:29, Caleb Connolly  wrote:
>
> From: Bhupesh Sharma 
>
> Some Qualcomm SoCs newer than SDM845 feature a so-called "7nm phy"
> driver, notable the SM8250 SoC which will gain U-Boot support in
> upcoming patches.
>
> Introduce a driver based on the Linux driver.
>
> Signed-off-by: Bhupesh Sharma 
> [code cleanup, align symbol names with Linux, switch to clk/reset_bulk APIs]
> Signed-off-by: Caleb Connolly 
> ---
>  drivers/phy/qcom/Kconfig  |   8 ++
>  drivers/phy/qcom/Makefile |   1 +
>  drivers/phy/qcom/phy-qcom-snps-femto-v2.c | 207 
> ++
>  3 files changed, 216 insertions(+)
>
> diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
> index 361dfb6e1126..b9fe608c2798 100644
> --- a/drivers/phy/qcom/Kconfig
> +++ b/drivers/phy/qcom/Kconfig
> @@ -18,8 +18,16 @@ config PHY_QCOM_QUSB2
> help
>   Enable this to support the Super-Speed USB transceiver on various
>   Qualcomm chipsets.
>
> +config PHY_QCOM_USB_SNPS_FEMTO_V2
> +   tristate "Qualcomm SNPS FEMTO USB HS PHY v2"
> +   depends on PHY && ARCH_SNAPDRAGON
> +   help
> + Enable this to support the Qualcomm Synopsys DesignWare Core 7nm
> + High-Speed PHY driver. This driver supports the Hi-Speed PHY which
> + is usually paired with Synopsys DWC3 USB IPs on MSM SOCs.
> +
>  config PHY_QCOM_USB_HS_28NM
> tristate "Qualcomm 28nm High-Speed PHY"
> depends on PHY && ARCH_SNAPDRAGON
> help
> diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
> index f6af985666a4..5f4db4a53788 100644
> --- a/drivers/phy/qcom/Makefile
> +++ b/drivers/phy/qcom/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
>  obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
>  obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
> +obj-$(CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2) += phy-qcom-snps-femto-v2.o
>  obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
>  obj-$(CONFIG_PHY_QCOM_USB_SS) += phy-qcom-usb-ss.o
> diff --git a/drivers/phy/qcom/phy-qcom-snps-femto-v2.c 
> b/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
> new file mode 100644
> index ..58eb01972402
> --- /dev/null
> +++ b/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + * Copyright (C) 2023 Bhupesh Sharma 
> + *
> + * Based on Linux driver
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define USB2_PHY_USB_PHY_UTMI_CTRL0 (0x3c)
> +#define SLEEPM BIT(0)
> +#define OPMODE_MASK GENMASK(4, 3)
> +#define OPMODE_NORMAL (0x00)
> +#define OPMODE_NONDRIVING BIT(3)
> +#define TERMSEL BIT(5)
> +
> +#define USB2_PHY_USB_PHY_UTMI_CTRL5 (0x50)
> +#define POR BIT(1)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0 (0x54)
> +#define SIDDQ BIT(2)
> +#define RETENABLEN BIT(3)
> +#define FSEL_MASK GENMASK(6, 4)
> +#define FSEL_DEFAULT (0x3 << 4)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON1 (0x58)
> +#define VBUSVLDEXTSEL0 BIT(4)
> +#define PLLBTUNE BIT(5)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON2 (0x5c)
> +#define VREGBYPASS BIT(0)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL1 (0x60)
> +#define VBUSVLDEXT0 BIT(0)
> +
> +#define USB2_PHY_USB_PHY_HS_PHY_CTRL2 (0x64)
> +#define USB2_AUTO_RESUME BIT(0)
> +#define USB2_SUSPEND_N BIT(2)
> +#define USB2_SUSPEND_N_SEL BIT(3)
> +
> +#define USB2_PHY_USB_PHY_CFG0 (0x94)
> +#define UTMI_PHY_DATAPATH_CTRL_OVERRIDE_EN BIT(0)
> +#define UTMI_PHY_CMN_CTRL_OVERRIDE_EN BIT(1)
> +
> +#define USB2_PHY_USB_PHY_REFCLK_CTRL (0xa0)
> +#define REFCLK_SEL_MASK GENMASK(1, 0)
> +#define REFCLK_SEL_DEFAULT (0x2 << 0)
> +
> +struct qcom_snps_hsphy {
> +   void __iomem *base;
> +   struct clk_bulk clks;
> +   struct reset_ctl_bulk resets;
> +};
> +
> +static inline void qcom_snps_hsphy_write_mask(void __iomem *base, u32 offset,
> + u32 mask, u32 val)
> +{
> +   u32 reg;
> +
> +   reg = readl_relaxed(base + offset);
> +
> +   reg &= ~mask;
> +   reg |= val & mask;
> +   writel_relaxed(reg, base + offset);
> +
> +   /* Ensure above write is completed */
> +   readl_relaxed(base + offset);

It looks like you have missed addressing comments related to this API.
Again, why do we need this special handling in U-Boot? Why not just
clrsetbits_le32()?

-Sumit

> +}
> +
> +static int qcom_snps_hsphy_usb_init(struct phy *phy)
> +{
> +   struct qcom_snps_hsphy *priv = dev_get_priv(phy->dev);
> +
> +   qcom_snps_hsphy_write_mask(priv->base, USB2_PHY_USB_PHY_CFG0,
> +  UTMI_PHY_CMN_CTRL_OVERRIDE_EN,
> +  UTMI_PHY_CMN_CTRL_OVERRIDE_EN);
> +   

  1   2   3   4   5   6   7   8   >