Re: [PATCH v5 05/24] ARM: tegra: Add device-tree for ASUS Transformer EeePad TF101

Dmitry Osipenko
2021-12-10T16:42:23Z

10.12.2021 18:46, Thierry Reding пишет:
...
>> + gpio@6000d000 {
>> + charging-enable-hog {
>> + gpio-hog;
>> + gpios = <TEGRA_GPIO(R, 6) GPIO_ACTIVE_HIGH>;
>> + output-low;
>> + };
>> + };
>
> Isn't this something that we may want to change at some point? My
> understanding is that GPIO hogs are permanent, so it won't be possible
> to grab GPIO R.6 and change this.
>
> Are there any plans to allow setting this at runtime?

I'm not aware about plans to change that charging hog.

It's not a problem to remove the hog. I don't understand why you're
saying that it's permanent. We have such hogs in Nexus7 DT for the 3G
modem pins. If we'll ever have a driver for that modem, then we will
remove those hogs, not a problem.

> [...]
>> + i2c2: i2c@7000c400 {
>> + status = "okay";
>> + clock-frequency = <100000>;
>> + };
>> +
>> + i2cmux {
>
> This doesn't belong here. The ordering is by unit-address and everything
> without unit-address needs to move after the nodes with unit-addresses
> and be sorted alphabetically.

Logically it belongs here, since mux uses i2c2. All other DTs do the same.

...
>> + memory-controller@7000f400 {
>> + nvidia,use-ram-code;
>> +
>> + emc-tables@3 {
>> + reg = <0x3>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + lpddr2 {
>> + compatible = "elpida,B8132B2PB-6D-F", "jedec,lpddr2-s4";
>> + revision-id1 = <1>;
>> + density = <2048>;
>> + io-width = <16>;
>> + };
>> +
>> + emc-table@25000 {
>
> Ugh... looking at the bindings for this the naming here is rather
> unfortunate. emc-tables@3 and emc-table@*... the top-level emc-tables
> are really tables, but the emc-table@* are really entries or rows in
> that table, not tables themselves. It's also rather unfortunate that we
> duplicate the frequency in both the "reg" and "clock-frequency"
> properties. One of them would've been enough.

It's emc-tables@3 here because initially there were other tables that I
removed during preparation of the DT for upstream. Those tables were
untested and looked questionable to me.

> Anyway, looks like this has basically been like this since forever, so
> not much that can be done about it.
>
> Again, the memory-controller node needs to be sorted differently. There
> are other occurrences of this throughout the file.

Please feel free to reorder it.