Re: RFC Need advice on reworking gpio-ep93xx.c to DT support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 22, 2021 at 6:00 PM Alexander Sverdlin
<alexander.sverdlin@xxxxxxxxx> wrote:
> On Mon, 2021-03-22 at 19:48 +0300, nikita.shubin@xxxxxxxxxxx wrote:
> > > > >  Note that the GPIO banks are registered a bit goofy, Ports C and F are
> > > > >  not in order. They have been that way since the original Cirrus "crater"
> > > > >  code base. If I remember correctly this was somewhere back in the 2.6.x
> > > > >  kernel. Please make sure the GPIO numbers stay the same so that any
> > > > >  userspace code does not break.
> > >
> > > >  I'm sceptical about this DT convertion.
> > >
> > > I'm in the same boat. One of the reasons I have not tried to convert it...
> >
> > I find this a bit confusing, so you think ep93xx shouldn't be touched at all ?
> >
> > AFAIK the question is reworking to DT or it will be dropped eventually:
> >
> > https://lore.kernel.org/lkml/CAK8P3a2VW8T+yYUG1pn1yR-5eU4jJXe1+M_ot6DAvfr2KyXCzQ@xxxxxxxxxxxxxx/
>
> I somehow missed the Jan Email even though I should be in the "maintainers"
> for EP93xx. I still know about thousands of devices running 24/7 with mainline Linux.
>
> Is it really about "DT conversion or die"?
> These systems really have very tight RAM and Flash budgets...

I would very much like to see the platform get modernized, though as far
as I'm concerned, the DT conversion is not the highest priority here.

One thing I really want to see happen is to move the few remaining
private implementations of the clk API over to the common-clk framework,
and once that is done, allow ep93xx to be built into the same kernel
as all other arm9 based platforms. There are still a couple of other platforms
that are missing a little work for this, but it should be doable.

Unfortunately, building a multiplatform kernel makes the kernel image
somewhat larger because it includes the code for CONFIG_OF, though
it does not have the runtime overhead for the DT data structures that you
get when running a DT-enabled kernel. Enabling CONFIG_USE_OF
increased the ep93xx_defconfig build for me by 128KB, replacing
the private clk driver with CONFIG_COMMON_CLOCK (and no driver)
on top added another 50KB, and finally enabling multiplatform added
another 2KB. In total, that is 2.7% total bloat in just the kernel image:

   text    data     bss     dec     hex filename
5677321 1119704   90556 6887581 69189d build/tmp/vmlinux
5782854 1143720   92188 7018762 6b190a build/tmp/vmlinux-use_of
5830020 1153408   89396 7072824 6bec38 build/tmp/vmlinux-of+clk
5829320 1153920   91308 7074548 6bf2f4 build/tmp/vmlinux-multi

I also think at some point in the distant future we will require DT boot for
everything, but that probably comes after most ARMv4T and earlier machines
have fallen out of use. I'd like to get a feeling for how EP93xx fits in there,
can you say what memory configurations are widely deployed and how
long you expect them to receive kernel upgrades in the future? Are these
systems that will definitely get put out of use at a particular time (e.g.
mobile phone infrastructure for older networks or fixed-time support
contracts), or are these systems that you expect to keep patching until
the hardware dies?

          Arnd



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux