[PATCH v5 4/7] board: asus: transformer: add ASUS Transformer T30 family support

[Tom Rini]

On Tue, Jun 06, 2023 at 10:40:53PM +0300, Svyatoslav Ryhel wrote:
> 
> 
> 6 червня 2023 р. 22:19:44 GMT+03:00, Tom Rini <trini at konsulko.com> написав(-ла):
> >On Tue, Jun 06, 2023 at 10:18:47AM +0300, Svyatoslav Ryhel wrote:
> >
> >> The ASUS Transformer T30 family are 2-in-1 detachable tablets
> >> and AiO developed by ASUS that run the Android operating system
> >> (TF600T runs Windows RT and P1801-T runs Android and Windows).
> >> The T30 Transformers feature a 10.1-inch display (apart P1801-T),
> >> an Nvidia Tegra 3 quad-core chip, 1/2 GB of RAM, and 16/32 GB of
> >> storage. Transformers board derives from Nvidia Cardhu development
> >> board.
> >> 
> >> This patch brings support for 7 known Transformer devices:
> >> - ASUS Transformer Prime TF201
> >> - ASUS Transformer Pad TF300T/TF300TG/TF300TL
> >> - ASUS VivoTab RT TF600T (Windows RT based)
> >> - ASUS Transformer Infinity TF700T
> >> - ASUS Transformer AiO P1801-T
> >> 
> >> Tested-by: Andreas Westman Dorcsak <hedmoo at yahoo.com> # all devices
> >> Signed-off-by: Svyatoslav Ryhel <clamor95 at gmail.com>
> >> ---
> >>  arch/arm/dts/Makefile                         |   7 +
> >>  arch/arm/dts/tegra30-asus-p1801-t.dts         |  17 +
> >>  arch/arm/dts/tegra30-asus-tf201.dts           |   9 +
> >>  arch/arm/dts/tegra30-asus-tf300t.dts          |  18 +
> >>  arch/arm/dts/tegra30-asus-tf300tg.dts         |   9 +
> >>  arch/arm/dts/tegra30-asus-tf300tl.dts         |   9 +
> >>  arch/arm/dts/tegra30-asus-tf600t.dts          |  89 +++++
> >>  arch/arm/dts/tegra30-asus-tf700t.dts          |  13 +
> >>  arch/arm/dts/tegra30-asus-transformer.dtsi    | 211 ++++++++++
> >>  arch/arm/mach-tegra/tegra30/Kconfig           |   5 +
> >>  board/asus/transformer-t30/Kconfig            |  23 ++
> >>  board/asus/transformer-t30/MAINTAINERS        |   6 +
> >>  board/asus/transformer-t30/Makefile           |  11 +
> >>  .../pinmux-config-transformer.h               | 365 ++++++++++++++++++
> >>  .../transformer-t30/transformer-t30-spl.c     |  41 ++
> >>  board/asus/transformer-t30/transformer-t30.c  | 201 ++++++++++
> >>  configs/p1801-t.config                        |   2 +
> >>  configs/tf201.config                          |   2 +
> >>  configs/tf300t.config                         |   2 +
> >>  configs/tf300tg.config                        |   2 +
> >>  configs/tf300tl.config                        |   2 +
> >>  configs/tf600t.config                         |   4 +
> >>  configs/tf700t.config                         |   2 +
> >>  configs/transformer_t30_defconfig             |  85 ++++
> >
> >Sorry for not noticing this part sooner.  Looking in the kernel,
> >arch/{riscv,powerpc}/Makefile both provide examples of how to automate
> >generating the resulting defconfigs directly. I think we really want
> >that, and also the config fragments need to be listed in the MAINTAINERS
> >file.
> 
> Not sure if adding this is a good idea, plus adding fragments into
> MAINTAINERS may cause even more issues. Iirc buildman uses it as a
> config source and defining multiple fragments may fail not only for
> boards under question, but those, already existing in u-boot, as well.

If this causes buildman problems then we'll need to figure out
something, but it shouldn't.

> Issue is not in the arch dir to tweak arch's makefile, fragments are
> used by some boards and issue lays in omitting their existence by
> system of autobuild.

Yes, and I'd like to set some good examples for the first config
fragments we're adding as I suspect you're the first person to notice
this works (as a feature not a happenstance) and others will make more
use if it for more than a few changes.  So I'd like to get things going
in the right direction.
> 
> >I also worry that none of these other configs will be caught by buildmn
> >and so won't be in CI at all, just the base.  Which isn't a big problem,
> >yet, but could be as more people use config fragments. I'm just noting
> >this secondary part and not saying you need to fix that as well.
> >
> 
> Buildman indeed is not catching any fragments, which already caused me issues since defconfigs are not as generic as I would like to (since else I get a big chunk of checks failed).
> 
> A good solution might be to tweak buildman to accept fragments if any are defined in the dedicated field of MAINTAINERS file. But that would be a major patchset to implement on the entire project scale.

Yes, I'm not sure how best to deal with fragments to start with, for
buildman.  But we don't need to solve that today for this series,
either.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230606/01632e8d/attachment.sig>