Re: [PATCH v3 9/9] board: qualcomm: Add support for QCS404 EVB

2022-07-25 Thread Tom Rini
On Tue, Jul 12, 2022 at 12:42:12PM +0530, Sumit Garg wrote:

> Add support for Qualcomm QCS404 SoC based evaluation board.
> 
> Features:
> - Qualcomm Snapdragon QCS404 SoC
> - 1GiB RAM
> - 8GiB eMMC, uSD slot
> 
> U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> For detailed build and boot instructions, refer to
> doc/board/qualcomm/qcs404.rst.
> 
> Signed-off-by: Sumit Garg 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v3 9/9] board: qualcomm: Add support for QCS404 EVB

2022-07-15 Thread Sumit Garg
On Thu, 14 Jul 2022 at 23:57, Stephan Gerhold  wrote:
>
> On Thu, Jul 14, 2022 at 01:10:45PM +0530, Sumit Garg wrote:
> > On Thu, 14 Jul 2022 at 01:02, Stephan Gerhold  wrote:
> > > Can you check how hard it would be to reuse the upstream QCS404 DT?
> > >
> >
> > It turned out to be patch [1] on top of this patch-set. Please help me
> > to test it on boards you have access to.
> >
> > [1] 
> > https://patchwork.ozlabs.org/project/uboot/patch/20220714073337.2298978-1-sumit.g...@linaro.org/
> >
>
> Thanks! Do you happen to have time to check the other custom bindings in
> SDM845 as well? I see two other differences there in addition to the
> pinctrl:
>
>   1. "qcom,msm-geni-uart": Linux has an additional "qcom,geni-se-qup"
>  node around that.
>

Yeah that is for a wrapper serial engine driver around UART, SPI, I2C,
I3C, etc. Text from "drivers/soc/qcom/qcom-geni-se.c":

/**
   * DOC: Software description
   *
   * GENI SE Wrapper driver is structured into 2 parts:
   *
   * geni_wrapper represents QUP Wrapper controller. This part of the driver
   * manages QUP Wrapper information such as hardware version, clock
   * performance table that is common to all the internal serial engines.
   *
   * geni_se represents serial engine. This part of the driver manages serial
   * engine information such as clocks, containing QUP Wrapper, etc. This part
   * of driver also supports operations (eg. initialize the concerned serial
   * engine, select between FIFO and DMA mode of operation etc.) that are
   * common to all the serial engines and are independent of serial interfaces.
   */

I am unsure if there really exists a use-case for that in u-boot but I
guess we should be able to add a dummy driver just to satisfy the
upstream Linux kernel DT binding.

>   2. The "qcom,pm8998-pwrkey" should be in an additional
>  "qcom,pm8998-pon" container node and then called
>  "qcom,pm8941-pwrkey".
>
>  Also, in U-Boot the keys are modelled as GPIOs which is a bit
>  strange (I don't think they can be set to output mode for example).
>  But it might be fine to keep that in the -u-boot.dtsi part for now.
>

Okay, I will try to look at these as follow up patches.

> I would be happy to investigate and test the remaining DB410c-specific
> parts (e.g. USB there). Cleaning up the DT differences has been on my
> TODO list for quite some time but I never got to it, sadly...
>

No worries, it's a community effort which often takes a backseat on
the TODO list.

-Sumit

> Thanks!
> Stephan


Re: [PATCH v3 9/9] board: qualcomm: Add support for QCS404 EVB

2022-07-14 Thread Stephan Gerhold
On Thu, Jul 14, 2022 at 01:10:45PM +0530, Sumit Garg wrote:
> On Thu, 14 Jul 2022 at 01:02, Stephan Gerhold  wrote:
> > Can you check how hard it would be to reuse the upstream QCS404 DT?
> >
> 
> It turned out to be patch [1] on top of this patch-set. Please help me
> to test it on boards you have access to.
> 
> [1] 
> https://patchwork.ozlabs.org/project/uboot/patch/20220714073337.2298978-1-sumit.g...@linaro.org/
> 

Thanks! Do you happen to have time to check the other custom bindings in
SDM845 as well? I see two other differences there in addition to the
pinctrl:

  1. "qcom,msm-geni-uart": Linux has an additional "qcom,geni-se-qup"
 node around that.

  2. The "qcom,pm8998-pwrkey" should be in an additional
 "qcom,pm8998-pon" container node and then called
 "qcom,pm8941-pwrkey".

 Also, in U-Boot the keys are modelled as GPIOs which is a bit
 strange (I don't think they can be set to output mode for example).
 But it might be fine to keep that in the -u-boot.dtsi part for now.

I would be happy to investigate and test the remaining DB410c-specific
parts (e.g. USB there). Cleaning up the DT differences has been on my
TODO list for quite some time but I never got to it, sadly...

Thanks!
Stephan


Re: [PATCH v3 9/9] board: qualcomm: Add support for QCS404 EVB

2022-07-14 Thread Sumit Garg
Hi Stephan,

On Thu, 14 Jul 2022 at 01:02, Stephan Gerhold  wrote:
>
> Hi Sumit,
>
> On Tue, Jul 12, 2022 at 12:42:12PM +0530, Sumit Garg wrote:
> > Add support for Qualcomm QCS404 SoC based evaluation board.
> >
> > Features:
> > - Qualcomm Snapdragon QCS404 SoC
> > - 1GiB RAM
> > - 8GiB eMMC, uSD slot
> >
> > U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> > For detailed build and boot instructions, refer to
> > doc/board/qualcomm/qcs404.rst.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> >  arch/arm/dts/Makefile|  1 +
> >  arch/arm/dts/qcs404-evb-uboot.dtsi   | 24 +++
> >  arch/arm/dts/qcs404-evb.dts  | 81 
> >  arch/arm/mach-snapdragon/Kconfig | 11 
> >  arch/arm/mach-snapdragon/Makefile|  2 +
> >  arch/arm/mach-snapdragon/sysmap-qcs404.c | 31 +
> >  board/qualcomm/qcs404-evb/Kconfig| 15 +
> >  board/qualcomm/qcs404-evb/MAINTAINERS|  6 ++
> >  board/qualcomm/qcs404-evb/Makefile   |  6 ++
> >  board/qualcomm/qcs404-evb/qcs404-evb.c   | 33 ++
> >  board/qualcomm/qcs404-evb/qcs404-evb.its | 64 +++
> >  configs/qcs404evb_defconfig  | 39 
> >  doc/board/qualcomm/index.rst |  1 +
> >  doc/board/qualcomm/qcs404.rst| 79 +++
> >  include/configs/qcs404-evb.h | 27 
> >  15 files changed, 420 insertions(+)
> >  create mode 100644 arch/arm/dts/qcs404-evb-uboot.dtsi
> >  create mode 100644 arch/arm/dts/qcs404-evb.dts
> >  create mode 100644 arch/arm/mach-snapdragon/sysmap-qcs404.c
> >  create mode 100644 board/qualcomm/qcs404-evb/Kconfig
> >  create mode 100644 board/qualcomm/qcs404-evb/MAINTAINERS
> >  create mode 100644 board/qualcomm/qcs404-evb/Makefile
> >  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.c
> >  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.its
> >  create mode 100644 configs/qcs404evb_defconfig
> >  create mode 100644 doc/board/qualcomm/qcs404.rst
> >  create mode 100644 include/configs/qcs404-evb.h
> >
> > [...]
> > diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
> > new file mode 100644
> > index 00..4f0ae20bdb
> > --- /dev/null
> > +++ b/arch/arm/dts/qcs404-evb.dts
> > @@ -0,0 +1,81 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Qualcomm QCS404 based evaluation board device tree source
> > + *
> > + * (C) Copyright 2022 Sumit Garg 
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "skeleton64.dtsi"
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. QCS404 EVB";
> > + compatible = "qcom,qcs404-evb", "qcom,qcs404";
> > + #address-cells = <0x2>;
> > + #size-cells = <0x2>;
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + aliases {
> > + serial0 = _uart;
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = <0 0x8000 0 0x4000>;
> > + };
> > +
> > + soc {
> > + #address-cells = <0x1>;
> > + #size-cells = <0x1>;
> > + ranges = <0x0 0x0 0x0 0x>;
> > + compatible = "simple-bus";
> > +
> > + pinctrl_north@130 {
> > + compatible = "qcom,tlmm-qcs404";
> > + reg = <0x130 0x20>;
> > +
> > + blsp1_uart2: uart {
> > + pins = "GPIO_17", "GPIO_18";
> > + function = "blsp_uart2";
> > + };
> > + };
> > +
>
> I know you're just following the example of the existing Qualcomm boards
> here but I think we should really avoid adding any more custom device
> trees that are inconsistent with the official (upstream) Linux bindings.
>
> Many other boards in U-Boot have moved to using the upstream Linux DTs
> as-is (with some additions in -u-boot.dtsi) and I think we should do the
> same for the Qualcomm boards. Judging from Tom's comments on other
> patches (e.g. [1]), this might even be a requirement now?
>

I overall agree with this and you can already see patches #2 and #3 in
this patch-set following this guideline.

> The SPMI fix I just sent for DB410c/DB820c [2] is a good example why it
> is important to have bindings consistent with Linux. Looking at your
> patch reminded me that I never sent this fix (thanks!).
>

Makes sense and I can echo with this while adding new boards support
its difficult to cope up with different DT expectations from Linux and
u-boot drivers.

> Can you check how hard it would be to reuse the upstream QCS404 DT?
>

It turned out to be patch [1] on top of this patch-set. Please help me
to test it on boards you have access to.

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20220714073337.2298978-1-sumit.g...@linaro.org/

-Sumit

> Thanks!
> Stephan
>
> [1]: 

Re: [PATCH v3 9/9] board: qualcomm: Add support for QCS404 EVB

2022-07-13 Thread Stephan Gerhold
Hi Sumit,

On Tue, Jul 12, 2022 at 12:42:12PM +0530, Sumit Garg wrote:
> Add support for Qualcomm QCS404 SoC based evaluation board.
> 
> Features:
> - Qualcomm Snapdragon QCS404 SoC
> - 1GiB RAM
> - 8GiB eMMC, uSD slot
> 
> U-boot is chain loaded by ABL in 64-bit mode as part of boot.img.
> For detailed build and boot instructions, refer to
> doc/board/qualcomm/qcs404.rst.
> 
> Signed-off-by: Sumit Garg 
> ---
>  arch/arm/dts/Makefile|  1 +
>  arch/arm/dts/qcs404-evb-uboot.dtsi   | 24 +++
>  arch/arm/dts/qcs404-evb.dts  | 81 
>  arch/arm/mach-snapdragon/Kconfig | 11 
>  arch/arm/mach-snapdragon/Makefile|  2 +
>  arch/arm/mach-snapdragon/sysmap-qcs404.c | 31 +
>  board/qualcomm/qcs404-evb/Kconfig| 15 +
>  board/qualcomm/qcs404-evb/MAINTAINERS|  6 ++
>  board/qualcomm/qcs404-evb/Makefile   |  6 ++
>  board/qualcomm/qcs404-evb/qcs404-evb.c   | 33 ++
>  board/qualcomm/qcs404-evb/qcs404-evb.its | 64 +++
>  configs/qcs404evb_defconfig  | 39 
>  doc/board/qualcomm/index.rst |  1 +
>  doc/board/qualcomm/qcs404.rst| 79 +++
>  include/configs/qcs404-evb.h | 27 
>  15 files changed, 420 insertions(+)
>  create mode 100644 arch/arm/dts/qcs404-evb-uboot.dtsi
>  create mode 100644 arch/arm/dts/qcs404-evb.dts
>  create mode 100644 arch/arm/mach-snapdragon/sysmap-qcs404.c
>  create mode 100644 board/qualcomm/qcs404-evb/Kconfig
>  create mode 100644 board/qualcomm/qcs404-evb/MAINTAINERS
>  create mode 100644 board/qualcomm/qcs404-evb/Makefile
>  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.c
>  create mode 100644 board/qualcomm/qcs404-evb/qcs404-evb.its
>  create mode 100644 configs/qcs404evb_defconfig
>  create mode 100644 doc/board/qualcomm/qcs404.rst
>  create mode 100644 include/configs/qcs404-evb.h
> 
> [...]
> diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
> new file mode 100644
> index 00..4f0ae20bdb
> --- /dev/null
> +++ b/arch/arm/dts/qcs404-evb.dts
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Qualcomm QCS404 based evaluation board device tree source
> + *
> + * (C) Copyright 2022 Sumit Garg 
> + */
> +
> +/dts-v1/;
> +
> +#include "skeleton64.dtsi"
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS404 EVB";
> + compatible = "qcom,qcs404-evb", "qcom,qcs404";
> + #address-cells = <0x2>;
> + #size-cells = <0x2>;
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + aliases {
> + serial0 = _uart;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0x8000 0 0x4000>;
> + };
> +
> + soc {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ranges = <0x0 0x0 0x0 0x>;
> + compatible = "simple-bus";
> +
> + pinctrl_north@130 {
> + compatible = "qcom,tlmm-qcs404";
> + reg = <0x130 0x20>;
> +
> + blsp1_uart2: uart {
> + pins = "GPIO_17", "GPIO_18";
> + function = "blsp_uart2";
> + };
> + };
> +

I know you're just following the example of the existing Qualcomm boards
here but I think we should really avoid adding any more custom device
trees that are inconsistent with the official (upstream) Linux bindings.

Many other boards in U-Boot have moved to using the upstream Linux DTs
as-is (with some additions in -u-boot.dtsi) and I think we should do the
same for the Qualcomm boards. Judging from Tom's comments on other
patches (e.g. [1]), this might even be a requirement now?

The SPMI fix I just sent for DB410c/DB820c [2] is a good example why it
is important to have bindings consistent with Linux. Looking at your
patch reminded me that I never sent this fix (thanks!).

Can you check how hard it would be to reuse the upstream QCS404 DT?

Thanks!
Stephan

[1]: https://lore.kernel.org/u-boot/20220601152800.GJ25375@bill-the-cat/
[2]: https://lore.kernel.org/u-boot/20220713191711.4155-1-step...@gerhold.net/