[PATCH v1 1/1] board: acer: picasso: add Acer Iconia Tab A500 support

[Svyatoslav Ryhel]

вт, 18 лют. 2025 р. о 11:35 Quentin Schulz <quentin.schulz at cherry.de> пише:
>
> Hi Svyatoslav,
>
> On 2/18/25 8:12 AM, Svyatoslav Ryhel wrote:
> > пн, 17 лют. 2025 р. о 18:51 Quentin Schulz <quentin.schulz at cherry.de> пише:
> >>
> >> Hi Svyatoslav,
> >>
> >> On 2/16/25 7:16 PM, Svyatoslav Ryhel wrote:
> >>> The Acer Iconia A500 is a tablet computer designed, developed and
> >>> marketed by Acer Inc. It is powered by 1 GHz Nvidia Tegra 2 processor
> >>> and 1GB DDR2 RAM. The A500 is sold with 64 GB, although both 16 GB
> >>> and 32 GB models are available.
> >>>
> >>> Signed-off-by: Svyatoslav Ryhel <clamor95 at gmail.com>
> >>> ---
> >>>    arch/arm/dts/Makefile                      |   1 +
> >>>    arch/arm/dts/tegra20-acer-a500-picasso.dts | 508 +++++++++++++++++++++
> >>>    arch/arm/mach-tegra/tegra20/Kconfig        |   5 +
> >>>    board/acer/picasso/Kconfig                 |  12 +
> >>>    board/acer/picasso/MAINTAINERS             |   7 +
> >>>    board/acer/picasso/Makefile                |   9 +
> >>>    board/acer/picasso/picasso.c               |  57 +++
> >>>    board/acer/picasso/picasso.env             |  18 +
> >>>    configs/picasso_defconfig                  |  83 ++++
> >>>    doc/board/acer/index.rst                   |   9 +
> >>>    doc/board/acer/picasso.rst                 | 125 +++++
> >>>    doc/board/index.rst                        |   1 +
> >>>    include/configs/picasso.h                  |  23 +
> >>>    13 files changed, 858 insertions(+)
> >>>    create mode 100644 arch/arm/dts/tegra20-acer-a500-picasso.dts
> >>>    create mode 100644 board/acer/picasso/Kconfig
> >>>    create mode 100644 board/acer/picasso/MAINTAINERS
> >>>    create mode 100644 board/acer/picasso/Makefile
> >>>    create mode 100644 board/acer/picasso/picasso.c
> >>>    create mode 100644 board/acer/picasso/picasso.env
> >>>    create mode 100644 configs/picasso_defconfig
> >>>    create mode 100644 doc/board/acer/index.rst
> >>>    create mode 100644 doc/board/acer/picasso.rst
> >>>    create mode 100644 include/configs/picasso.h
> >>>
> >>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> >>> index 0bf3697bdbe..acea0cc2ec1 100644
> >>> --- a/arch/arm/dts/Makefile
> >>> +++ b/arch/arm/dts/Makefile
> >>> @@ -84,6 +84,7 @@ dtb-$(CONFIG_ARCH_MESON) += \
> >>>        meson-a1-ad401.dtb
> >>>
> >>>    dtb-$(CONFIG_ARCH_TEGRA) += \
> >>> +     tegra20-acer-a500-picasso.dtb \
> >>>        tegra20-asus-sl101.dtb \
> >>>        tegra20-asus-tf101.dtb \
> >>>        tegra20-asus-tf101g.dtb \
> >>> diff --git a/arch/arm/dts/tegra20-acer-a500-picasso.dts b/arch/arm/dts/tegra20-acer-a500-picasso.dts
> >>> new file mode 100644
> >>> index 00000000000..0c301483180
> >>> --- /dev/null
> >>> +++ b/arch/arm/dts/tegra20-acer-a500-picasso.dts
> >>
> >> Small drive-by comment.
> >>
> >> This is quite different from the Device Tree in the Linux kernel tree,
> >> and it hasn't been changed a lot in the last few years.
> >>
> >> 1) Is there any reason for not sync'ing with upstream Linux kernel
> >> instead of having our own Device Tree?
> >> 2) Do you think it'd be possible to use OF_UPSTREAM instead which would
> >> make it possible to use the device tree from the Linux kernel (it is
> >> available in dts/upstream/src/arm/nvidia/tegra20-acer-a500-picasso.dts)?
> >> I don't think it's a straightforward thing to do but haven't do it
> >> myself, so no clue what's required and the amount of effort to put into
> >> it. The benefit is that fixes to the DT will eventually make it to
> >> U-Boot as well and we hopefully lower the maintenance burden on U-Boot
> >> contributors/maintainers.
> >>
> >> Cheers,
> >> Quentin
> >
> > Short answers yes and yes.
> >
> > Long answer:
> > 1. Using Linux Kernel device tree will result in at least total
> > failure of entire video subsystem since Linux gpu/drm changed
> > extremely quick. All devices I have submitted, including A500 heavily
> > relay on video output to be operated correctly (being a production
> > devices there is no exposed uart or any other output, besides the
> > panel). This is only at the first glance, there may be more under the
> > surface. At the same time, even if we switch to Linux device trees,
> > this will not remove need of *-u-boot.dts to adjust Linux tree to
> > U-Boot reality.
> >
>
> Yeah, most if not all our Rockchip-based boards have a -u-boot.dtsi to
> fix things up but mainly add binman nodes and add bootph properties
> (though those should be upstreamable to the kernel DTS, just that we're
> still struggling to get it right on the first try and kernel DTS updates
> really takes a long time for us to be merged in U-Boot.
>
> > 2. It is possible and it is even one of my current priorities.
> > Hopefully, by the fall I will be able to configure existing frameworks
> > and drivers to comply existing Linux trees. A small example, atm
> > U-Boot has no helpers to parse of_graph bindings, which are heavily
> > used by Linux to link video devices (that is expected since there is
> > not so much devices are using video output so no one bothered). This
> > makes most Linux bindings of video devices useless for U-Boot. Don't
> > assume that each or nearly each framework has such flows, they are
> > uncommon, but nonetheless they occur and destroy full picture.
>
> I think Qualcomm does have support for display in U-Boot as well, maybe
> there's something to be learned/adapted/shared with them as well.
>

Qualcomm does not initiate entire video pipe from scratch and does not
support use of u-boot as primary bootloader.

> In any case, good luck and have fun!
>
> Cheers,
> Quentin