Re: [PATCH v5 4/7] board: asus: transformer: add ASUS Transformer T30 family support
Svyatoslav Ryhel
clamor95 at gmail.com
Tue Jun 6 22:00:56 CEST 2023
6 червня 2023 р. 22:47:23 GMT+03:00, Tom Rini <trini at konsulko.com> написав(-ла):
>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.
Fragments system is by far the best solution for situations like with Asus Transformers.
>>
>> >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.
>
Since I place myself as a maintainer of all devices in this patchset you can count on me if there will be any changes to the fragment system. Additionally, I will experiment more with transformer defconfigs (this is definitely not all changes I am interested in) to improve current state inline with u-boot development.
More information about the U-Boot
mailing list