[PATCH v2 00/12] memory: tegra: Driver unification
Dmitry Osipenko
digetx at gmail.com
Tue Jun 1 13:02:18 PDT 2021
01.06.2021 22:38, Dmitry Osipenko пишет:
> 01.06.2021 20:59, Thierry Reding пишет:
>> From: Thierry Reding <treding at nvidia.com>
>>
>> Hi,
>>
>> this set of patches converges the feature sets of the pre-Tegra186 and
>> the post-Tegra186 memory controller drivers such that newer chips can
>> take advantage of some features that were previously only implemented
>> on earlier chips.
>>
>> Note that this looks a bit daunting from a diffstat point of view but
>> the bulk of this is in the first two patches that basically shuffle
>> around where some of the per-memory-client register definitions are
>> located, hence the big number of changed lines.
>>
>> Changes in v2:
>> - split patches up a bit for smaller, logical changes
>> - add better documentation for ->probe() callback
>> - use SET_SYSTEM_SLEEP_OPS where appropriate
>> - include Tegra194 separation patch
>> - use prefix for global variables
>> - drop commented-out code
>
> Everything looks and works good, thank you.
>
> I made a minor comment about the function which can be made static,
> perhaps you could improve it locally if you will take these patches via
> Tegra tree.
>
./scripts/bloat-o-meter -d ./vmlinux.old ./vmlinux.new
add/remove: 6/4 grow/shrink: 4/2 up/down: 2208/-240 (1968)
Data old new delta
tegra124_mc_clients 2948 3484 +536
tegra30_mc_clients 2904 3432 +528
tegra114_mc_clients 2860 3380 +520
tegra20_mc_clients 2288 2704 +416
tegra_mc_status_names - 128 +128
tegra_mc_error_names - 32 +32
tegra30_mc_ops - 20 +20
tegra20_mc_ops - 20 +20
__initcall__kmod_tegra_mc__252_848_tegra_mc_init3 - 4 +4
__initcall__kmod_tegra124_emc__239_1536_tegra_emc_driver_init6 - 4 +4
__initcall__kmod_tegra_mc__252_980_tegra_mc_init3 4 - -4
__initcall__kmod_tegra124_emc__237_1536_tegra_emc_driver_init6 4 - -4
__func__ 36101 36085 -16
error_names 32 - -32
_rs 15764 15708 -56
status_names 128 - -128
Total: Before=3674440, After=3676408, chg +0.05%
The +2KB in size is okay, I expected it would be worse.
More information about the linux-arm-kernel
mailing list