[PATCH v5 4/7] board: asus: transformer: add ASUS Transformer T30 family support
Svyatoslav Ryhel
clamor95 at gmail.com
Thu Jun 8 21:05:30 CEST 2023
чт, 8 черв. 2023 р. о 20:09 Tom Rini <trini at konsulko.com> пише:
>
> On Thu, Jun 08, 2023 at 07:54:54PM +0300, Svyatoslav Ryhel wrote:
> > чт, 8 черв. 2023 р. о 19:40 Tom Rini <trini at konsulko.com> пише:
> > >
> > > On Thu, Jun 08, 2023 at 06:11:57PM +0300, Svyatoslav Ryhel wrote:
> > > > вт, 6 черв. 2023 р. о 22:47 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.
> > > >
> > > > Adding fragments into MAINTAINERS does not cause issues but seems to
> > > > not have any effect either.
> > >
> > > Well, get_maintainers.pl will now report who owns them, which it didn't
> > > before, yes?
> > >
> >
> > It does report me if get_maintainers.pl is used anyway, even if no
> > files are specified in MAINTAINERS
>
> As maintainer, or as git heuristics? But all the same, the rule about
> defconfigs needing to be in MAINTAINERS entires should extend to config
> fragments.
>
> > > > > > 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.
> > > >
> > > > May you specify more, what do you exactly want from me to change.
> > >
> > > Well, as this just came up on the IRC channel as well as someone else
> > > noticed fragments work, it would be nice to figure out what needs to
> > > be added so they can live in $(BOARDDIR) if possible. Or something that
> > > doesn't cause a further explosion of files in configs/ (which is already
> > > unwieldy).
> >
> > I see your point but it is definitely beyond this patchset cover.
>
> Yes, it's not stopping this first patch-set.
>
> > > > > > >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.
> > > > >
> > > >
> > > > Does this patchset require any additional changes to be accepted? Have
> > > > in mind that most likely there will be more patchsets for
> > > > transformers.
> > >
> > > To be clear, it needs the CI issues that I pointed out in Tom W's pull
> > > request to be fixed.
> >
> > This was done in v5 iteration. I have fixed CI issues you have pointed
> > to. Hopefully, how checks pass.
>
> Were you able to use GitHub / Azure to get a round of CI run?
>
I have set Gitlab CI pipelines, once they pass I will upload the next
patchset iteration with changes to the MAINTAINERS file you have asked
for.
Best regards,
Svyatoslav R.
> --
> Tom
More information about the U-Boot
mailing list