On Fri, Jun 23, 2023 at 05:19:09PM +0300, Svyatoslav Ryhel wrote:
23 червня 2023 р. 17:11:35 GMT+03:00, Thierry Reding thierry.reding@gmail.com написав(-ла):
On Fri, Jun 23, 2023 at 02:51:54PM +0300, Svyatoslav Ryhel wrote:
23 червня 2023 р. 14:32:30 GMT+03:00, Thierry Reding thierry.reding@gmail.com написав(-ла):
On Fri, Jun 23, 2023 at 08:55:57AM +0300, Svyatoslav Ryhel wrote: [...]
diff --git a/board/asus/transformer-t30/pinmux-config-transformer.h b/board/asus/transformer-t30/pinmux-config-transformer.h new file mode 100644 index 0000000000..96ff45d375 --- /dev/null +++ b/board/asus/transformer-t30/pinmux-config-transformer.h @@ -0,0 +1,365 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/*
- Copyright (c) 2010-2013, NVIDIA CORPORATION. All rights reserved.
- Copyright (c) 2021, Svyatoslav Ryhel.
- */
I don't recall if we discussed this during upstreaming of the Linux device tree files, but shortly after the initial support for Tegra20 and Tegra30 was upstreamed (both in U-Boot and in Linux) we decided to move towards generating the pinmux configuration for the various consumers (i.e. U-Boot and Linux) from data tables using a set of scripts. This was done because we noticed that various inconsistencies kept creeping into the various drivers/tables.
You can find the scripts for this here:
https://github.com/NVIDIA/tegra-pinmux-scripts
I think there'd be some benefit if these new boards were also converted to use these scripts.
True, but there is no driver for pinmux which can utilize device tree, instead u-boot relies on board header. I see the benefit of these pinmux nodes only if I can verify that they are correct and do not brake devices. Would be really bad if at some point devices brake cause nodes were not tested.
Additionally, shouldn't all supported boards be converted first?
The above repository contains a script that will generate the board headers for U-Boot based on a more generic definition of the pinmux configuration. Many devices already have headers that were generated from those scripts, though it's mostly later boards (Tegra124 and onwards).
That said, for many of these boards a spreadsheet exists that contains these settings and the tables are generated from that spreadsheet. For many of these OEM devices I suspect no such spreadsheet exists, and it doesn't necessarily make sense to transcribe this into the tables and then convert into board header & DTS snippets. It might be nice to do for consistency, but I'll leave it up to you.
Current tables are dumped from working vendor kernels. It is not that I like this approach, but I would rather leave an existing setup since it is well tested and confirmed to be stable enough. No one knows what htc and asus did with those pins, at least publicly.
Okay, fair enough.
Thierry