Re: [PATCH 0/2] i2c: tegra: allow compiling out support for Tegra's special constrollers

[Michał Mirosław]

On Mon, Jan 17, 2022 at 06:37:12PM +0300, Dmitry Osipenko wrote:
> 17.01.2022 00:39, Michał Mirosław пишет:
> > On Sun, Jan 16, 2022 at 09:34:42PM +0300, Dmitry Osipenko wrote:
> >> 16.01.2022 21:03, Michał Mirosław пишет:
> >>> On Sun, Jan 16, 2022 at 08:54:08PM +0300, Dmitry Osipenko wrote:
> >>>> 16.01.2022 19:02, Michał Mirosław пишет:
> >>>>> To patches that, combined, reduce I2C driver's code by ~2kB and a bit
> >>>>> from runtime overhead for non-Tegra20 or non-Tegra210 builds.
> >>>>>
> >>>>> Michał Mirosław (2):
> >>>>>   i2c: tegra: allow DVC support to be compiled out
> >>>>>   i2c: tegra: allow VI support to be compiled out
> >>>>>
> >>>>>  drivers/i2c/busses/Kconfig     | 16 ++++++++++++++++
> >>>>>  drivers/i2c/busses/i2c-tegra.c | 35 +++++++++++++++++++++-------------
> >>>>>  2 files changed, 38 insertions(+), 13 deletions(-)
> >>>>>
> >>>>
> >>>> 2KB is a too small difference to justify the ifdefs and Kconfig entries,
> >>>> IMO.
> >>>
> >>> Maybe I should have mentioned that it's ~20%? With my "embedded" hat on:
> >>> I think it might be small, but sometimes it is the difference between
> >>> bootable kernel or one too big.
> >>
> >> 10KB is a small size too. I'm very doubtful that such changes make any
> >> real difference in practice.
> >>
> >> Much more practical should be to modularize more kernel code. You should
> >> be able to squeeze zImage down to 3MB without any code changes by
> >> toggling more kernel config options to =m. Try to use grate_defconfig
> >> [1] for the base, that is what postmarketOS kernel build uses.
> > 
> > For normal system this solution is workable. But for recovery, where you
> > have to fit kernel+initrd in whatever small partition is provided (like
> > eg. in Transformers 8MiB), it becomes a problem from time to time.
> > (In this case, modules make it worse due to additional overhead in
> > kernel and userspace).
> 
> My point is that 2KB very likely won't change anything for you. I'd
> suggest to take a look at a more "fat" drivers, like DRM/host1x for
> example. I suppose it should be possible to save at least couple
> hundreds KB by trimming those fat drivers.

No doubt we can find more code to trim. :-) This one was cheap and easy,
though. BTW, I worked around host1x size by using simpledrmfb instead,
so I'm not sure there will be much benefit to digging there.

Best Regards
Michał Mirosław