From: Arnd Bergmann <arnd@arndb.de>
To: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Cc: "nikita.shubin@maquefel.me" <nikita.shubin@maquefel.me>,
Hartley Sweeten <hartleys@visionengravers.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
"bgolaszewski@baylibre.com" <bgolaszewski@baylibre.com>,
Arnd Bergmann <arnd.bergmann@linaro.org>
Subject: Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
Date: Mon, 22 Mar 2021 23:31:37 +0100 [thread overview]
Message-ID: <CAK8P3a0nvComAVhUSK9NgnakLjqqVvnFJRx6oVciuG4deK7VDQ@mail.gmail.com> (raw)
In-Reply-To: <d7685a8561d9be5ce6269bbf5d600f8f3f5f743b.camel@gmail.com>
On Mon, Mar 22, 2021 at 6:00 PM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> On Mon, 2021-03-22 at 19:48 +0300, nikita.shubin@maquefel.me 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@mail.gmail.com/
>
> 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
next prev parent reply other threads:[~2021-03-22 22:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 12:19 RFC Need advice on reworking gpio-ep93xx.c to DT support nikita.shubin
2021-03-22 12:25 ` Linus Walleij
2021-03-22 15:43 ` Hartley Sweeten
2021-03-22 15:59 ` Alexander Sverdlin
2021-03-22 16:14 ` Hartley Sweeten
2021-03-22 16:48 ` nikita.shubin
2021-03-22 17:00 ` Alexander Sverdlin
2021-03-22 22:31 ` Arnd Bergmann [this message]
2021-03-23 6:57 ` Alexander Sverdlin
2021-03-23 8:45 ` Arnd Bergmann
2021-05-25 8:44 ` Geert Uytterhoeven
2021-03-23 8:21 ` Linus Walleij
2021-03-22 16:20 ` nikita.shubin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK8P3a0nvComAVhUSK9NgnakLjqqVvnFJRx6oVciuG4deK7VDQ@mail.gmail.com \
--to=arnd@arndb.de \
--cc=alexander.sverdlin@gmail.com \
--cc=arnd.bergmann@linaro.org \
--cc=bgolaszewski@baylibre.com \
--cc=hartleys@visionengravers.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=nikita.shubin@maquefel.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).