All of lore.kernel.org
 help / color / mirror / Atom feed
* RFC Need advice on reworking gpio-ep93xx.c to DT support
@ 2021-03-22 12:19 nikita.shubin
  2021-03-22 12:25 ` Linus Walleij
  2021-03-22 15:43 ` Hartley Sweeten
  0 siblings, 2 replies; 13+ messages in thread
From: nikita.shubin @ 2021-03-22 12:19 UTC (permalink / raw)
  To: linux-gpio, Linus Walleij, hsweeten, Alexander Sverdlin, bgolaszewski

Dear all, after studying the question i've came up with the following suggestion:

- split ep93xx_gpio_resource into per port platform device:

So instead of:
```
static struct resource ep93xx_gpio_resource[] = {
DEFINE_RES_MEM(EP93XX_GPIO_PHYS_BASE, 0xcc),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO_AB),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO0MUX),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO1MUX),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO2MUX),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO3MUX),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO4MUX),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO5MUX),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO6MUX),
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO7MUX),
};

static struct platform_device ep93xx_gpio_device = {
.name = "gpio-ep93xx",
.id = -1,
.num_resources = ARRAY_SIZE(ep93xx_gpio_resource),
.resource = ep93xx_gpio_resource,
};
```

We will have something like this for each port:
```
static struct resource ep93xx_gpio_A_resource[] = {
DEFINE_RES_MEM(EP93XX_GPIO_PHYS_BASE + DATA, 0x04),
DEFINE_RES_MEM(EP93XX_GPIO_PHYS_BASE + DIRECTION, 0x04),
DEFINE_RES_MEM(EP93XX_GPIO_PHYS_BASE + INTERRUPT, 0x2c), /** only port A/B/F*/
DEFINE_RES_IRQ(IRQ_EP93XX_GPIO_AB), /** only port A/B*/
... /* IRQS only for port F*/
};

static struct platform_device ep93xx_gpio_A_device = {
.name = "gpio-ep93xx",
.id = -1,
.num_resources = ARRAY_SIZE(ep93xx_gpio_A_resource),
.resource = ep93xx_gpio_A_resource,
};
```

And they will registered separately.

I think this will allow more transparent transition to DT

- rework gpio-ep93xx.c to handle each platform device instance separately
- add processing for the following device tree (example):

Showing only ports A, F and no interrupt capable C:
```
gpio0: gpio@80840000 {
compatible = "cirrus,ep93xx-gpio-a", "cirrus,ep93xx-gpio";
label = "A";
reg = <0x80840000 0x04>,
<0x80840010 0x04>,
<0x80840090 0x1c>;
reg-names = "data", "dir", "int";
gpio-controller;
interrupt-controller;
interrupt-parent = <&vic1>;
interrupts = <27>;
};

gpio2: gpio@80840008 {
compatible = "cirrus,ep93xx-gpio";
label = "C";
reg = <0x80840008 0x04>,
<0x80840018 0x04>;
reg-names = "data", "dir";
gpio-controller;
};

gpio5: gpio@80840030 {
compatible = "cirrus,ep93xx-gpio-f", "cirrus,ep93xx-gpio";
label = "F";
reg = <0x80840030 0x04>,
<0x80840034 0x04>,
<0x8084004C 0x1c>;
reg-names = "data", "dir", "int";
gpio-controller;
interrupt-controller;
interrupts-extended= <&vic0 19 20 21 22>,
<&vic1 15 16 17 18>;
};
```

So the work will be split into 2 stages:
- breaking gpio platform data into pieces, adapting gpio-ep93xx.c
- adding DT support for gpio-ep93xx.c

Please advise me on this issue.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  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
  1 sibling, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-03-22 12:25 UTC (permalink / raw)
  To: Nikita Shubin
  Cc: linux-gpio, Hartley Sweeten, Alexander Sverdlin, Bartosz Golaszewski

On Mon, Mar 22, 2021 at 1:19 PM <nikita.shubin@maquefel.me> wrote:

> So the work will be split into 2 stages:
> - breaking gpio platform data into pieces, adapting gpio-ep93xx.c
> - adding DT support for gpio-ep93xx.c
>
> Please advise me on this issue.

If that is your preferred way of working then use that, seems OK to me.

What I have done traditionally has been lazier: I just write the specification
for the device tree bindings as the hardware shall be described (noadays
using the YAML syntax) then adapt the driver to probing from that.

Then when all non-DT users are gone I just delete the old code.

During transitions from boardfile to DT we have often taken this
approach:

1. Add a specific DT boardfile
2. Make this boot
3. Add DT support to all drivers
4. Delete the old boardfiles
5. Delete the old platform data handling from the drivers

As you see, this makes the kernel bigger, then shrinks it.
This is what we have usually done: not refactor stuff into the
form it needs for DT support, instead implement DT on the
side and then eventually delete the old non-DT code.

Smoother transitions can work as well, I just never attempted
that, believeing that it is much more work.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: RFC Need advice on reworking gpio-ep93xx.c to DT support
  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:20   ` nikita.shubin
  1 sibling, 2 replies; 13+ messages in thread
From: Hartley Sweeten @ 2021-03-22 15:43 UTC (permalink / raw)
  To: nikita.shubin, linux-gpio, Linus Walleij, Alexander Sverdlin,
	bgolaszewski

On Monday, March 22, 2021 5:20 AM, <nikita.shubin@maquefel.me> wrote:

> Showing only ports A, F and no interrupt capable C:

Are you just going to drop the other GPIO ports?

The EP93xx has eight 8-bit ports total (Ports A-H). Only 3 port support interrupts: A B and F. Posts A and B share a single interrupt and port F has an interrupt for each pin.

Depending on the chip type  (01, 02, 07, 12, or 15) not all the GPIOs are pinned out due to the chip pin count. But the registers exist so the current GPIO support always registers all the ports.

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.

Port A - GPIO[0-7]	<- interrupt capable
Port B - GPIO[8-15]	<- interrupt capable
Port F - GPIO[16-23]	<- interrupt capable
Port D - GPIO[24-31]
Port E - GPIO[32-39]
Port C - GPIO[40-47]
Port G - GPIO[48-55]
Port H - GPIO[56-63]

I look forward to seeing patches.

Hartley

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 15:43 ` Hartley Sweeten
@ 2021-03-22 15:59   ` Alexander Sverdlin
  2021-03-22 16:14     ` Hartley Sweeten
  2021-03-23  8:21     ` Linus Walleij
  2021-03-22 16:20   ` nikita.shubin
  1 sibling, 2 replies; 13+ messages in thread
From: Alexander Sverdlin @ 2021-03-22 15:59 UTC (permalink / raw)
  To: Hartley Sweeten, nikita.shubin, linux-gpio, Linus Walleij, bgolaszewski

Hello Hartley,

On Mon, 2021-03-22 at 15:43 +0000, Hartley Sweeten wrote:
> > Showing only ports A, F and no interrupt capable C:
> 
> Are you just going to drop the other GPIO ports?
> 
> The EP93xx has eight 8-bit ports total (Ports A-H). Only 3 port support interrupts: A B and F. Posts A and B share a single interrupt and port F has an interrupt for each pin.
> 
> Depending on the chip type  (01, 02, 07, 12, or 15) not all the GPIOs are pinned out due to the chip pin count. But the registers exist so the current GPIO support always registers all the ports.
> 
> 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.
Not only will it make the kernel bigger (back then is was a concern),
but they also do not guarantee any order of GPIOs with DT:


https://patchwork.kernel.org/comment/24009887/

-- 
Alexander Sverdlin.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 15:59   ` Alexander Sverdlin
@ 2021-03-22 16:14     ` Hartley Sweeten
  2021-03-22 16:48       ` nikita.shubin
  2021-03-23  8:21     ` Linus Walleij
  1 sibling, 1 reply; 13+ messages in thread
From: Hartley Sweeten @ 2021-03-22 16:14 UTC (permalink / raw)
  To: Alexander Sverdlin, nikita.shubin, linux-gpio, Linus Walleij,
	bgolaszewski

On Monday, March 22, 2021 9:00 AM, Alexander Sverdlin wrote:
> On Mon, 2021-03-22 at 15:43 +0000, Hartley Sweeten wrote:
>>> Showing only ports A, F and no interrupt capable C:
>> 
>> Are you just going to drop the other GPIO ports?
>> 
>> The EP93xx has eight 8-bit ports total (Ports A-H). Only 3 port support
>> interrupts: A B and F. Ports A and B share a single interrupt and port F
>> has an interrupt for each pin.
>> 
>> Depending on the chip type  (01, 02, 07, 12, or 15) not all the GPIOs are
>> pinned out due to the chip pin count. But the registers exist so the current
>> GPIO support always registers all the ports.
>> 
>> 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...

> Not only will it make the kernel bigger (back then is was a concern), but
> they also do not guarantee any order of GPIOs with DT:
>
> https://patchwork.kernel.org/comment/24009887/

I bigger kernel can be an issue for some ep93xx boards. Depending on the SDRAM
chip size and how they are connected, some boards can have as small as a 2MiB
segment size. That limits the size of kernel that can be loaded. I had a lot of issues
with a TS-7200 board booting until I figured that out.

Hartley

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 15:43 ` Hartley Sweeten
  2021-03-22 15:59   ` Alexander Sverdlin
@ 2021-03-22 16:20   ` nikita.shubin
  1 sibling, 0 replies; 13+ messages in thread
From: nikita.shubin @ 2021-03-22 16:20 UTC (permalink / raw)
  To: Hartley Sweeten, linux-gpio, Linus Walleij, Alexander Sverdlin,
	bgolaszewski

Dear Hartley,

> Are you just going to drop the other GPIO ports?

Of course i am not going to drop anything, i just showed binding for three types of ep93xx ports to shrink letter a bit.

This part is just an example of what i proposing for device tree.

We generally have:

- A/B port that share IRQ
- F port with IRQ for each line
- other ports that have nothing more than direction and data registers

> 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.

Thank you for pointing this out.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 16:14     ` Hartley Sweeten
@ 2021-03-22 16:48       ` nikita.shubin
  2021-03-22 17:00         ` Alexander Sverdlin
  0 siblings, 1 reply; 13+ messages in thread
From: nikita.shubin @ 2021-03-22 16:48 UTC (permalink / raw)
  To: Hartley Sweeten, Alexander Sverdlin, linux-gpio, Linus Walleij,
	bgolaszewski

Dear Alexander and Hartley.

22.03.2021, 19:14, "Hartley Sweeten" <hartleys@visionengravers.com>:
> On Monday, March 22, 2021 9:00 AM, Alexander Sverdlin wrote:
>>  On Mon, 2021-03-22 at 15:43 +0000, Hartley Sweeten 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/



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 16:48       ` nikita.shubin
@ 2021-03-22 17:00         ` Alexander Sverdlin
  2021-03-22 22:31           ` Arnd Bergmann
  0 siblings, 1 reply; 13+ messages in thread
From: Alexander Sverdlin @ 2021-03-22 17:00 UTC (permalink / raw)
  To: nikita.shubin, Hartley Sweeten, linux-gpio, Linus Walleij,
	bgolaszewski, Arnd Bergmann

Hello Nikita, Arnd!

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...

-- 
Alexander Sverdlin.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 17:00         ` Alexander Sverdlin
@ 2021-03-22 22:31           ` Arnd Bergmann
  2021-03-23  6:57             ` Alexander Sverdlin
  2021-05-25  8:44             ` Geert Uytterhoeven
  0 siblings, 2 replies; 13+ messages in thread
From: Arnd Bergmann @ 2021-03-22 22:31 UTC (permalink / raw)
  To: Alexander Sverdlin
  Cc: nikita.shubin, Hartley Sweeten, linux-gpio, Linus Walleij,
	bgolaszewski, Arnd Bergmann

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 22:31           ` Arnd Bergmann
@ 2021-03-23  6:57             ` Alexander Sverdlin
  2021-03-23  8:45               ` Arnd Bergmann
  2021-05-25  8:44             ` Geert Uytterhoeven
  1 sibling, 1 reply; 13+ messages in thread
From: Alexander Sverdlin @ 2021-03-23  6:57 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: nikita.shubin, Hartley Sweeten, linux-gpio, Linus Walleij,
	bgolaszewski, Arnd Bergmann

Hello Arnd!

On Mon, 2021-03-22 at 23:31 +0100, Arnd Bergmann wrote:
> 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

This doesn't sound so bad as I expected. I still had no chance to figure out
much bigger increase from 5.4 to 5.12 ;)

>    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

The systems I know have 32MB RAM and 16MB Flash (but only 2MB was reserved for
compressed kernel back then).

> 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?

Yes, I expect them to work (and be patched) until they die and this
may take another decade ;)

-- 
Alexander Sverdlin.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 15:59   ` Alexander Sverdlin
  2021-03-22 16:14     ` Hartley Sweeten
@ 2021-03-23  8:21     ` Linus Walleij
  1 sibling, 0 replies; 13+ messages in thread
From: Linus Walleij @ 2021-03-23  8:21 UTC (permalink / raw)
  To: Alexander Sverdlin
  Cc: Hartley Sweeten, nikita.shubin, linux-gpio, bgolaszewski

On Mon, Mar 22, 2021 at 4:59 PM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:

> I'm sceptical about this DT convertion.
> Not only will it make the kernel bigger (back then is was a concern),
> but they also do not guarantee any order of GPIOs with DT:
>
> https://patchwork.kernel.org/comment/24009887/

I guess what you're actually saying is that you are using the GPIO
sysfs for interacting with GPIOs.

I am a bit troubled if boardfiles and old GPIO global numbers are
in the same legacy bundle but seems like so, because the device
tree ambition is to make resources abstract, not enumerated.

For good or for bad, it's not like I don't see the problem of supporting
legacy code.

I think a good approach is to create a DT-specific boardfile so that
systems can be booted from DT on EP93xx and then migrate those
boards that can. Then we see about the rest. It should also mean that
if you don't activate DT support the impact should be minimal.

Yours,
Linus Walleij

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-23  6:57             ` Alexander Sverdlin
@ 2021-03-23  8:45               ` Arnd Bergmann
  0 siblings, 0 replies; 13+ messages in thread
From: Arnd Bergmann @ 2021-03-23  8:45 UTC (permalink / raw)
  To: Alexander Sverdlin
  Cc: nikita.shubin, Hartley Sweeten, linux-gpio, Linus Walleij,
	bgolaszewski, Arnd Bergmann

On Tue, Mar 23, 2021 at 7:57 AM Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> On Mon, 2021-03-22 at 23:31 +0100, Arnd Bergmann wrote:
>
> This doesn't sound so bad as I expected. I still had no chance to figure out
> much bigger increase from 5.4 to 5.12 ;)
>
> >    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
>
> The systems I know have 32MB RAM and 16MB Flash (but only 2MB was reserved for
> compressed kernel back then).

I see, so with 32MB/2MB you are hitting both limits already and are using a
rather customized user space, and 200KB is both significant and in the
within range of the bloat you can expect from the other updates over one
or two years.

I expect the bloat problem to gradually get worse over time, as fewer
developers care about the sub-256MB machines than they used to.

On the plus side, there should be some gains in enabling
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION in the future, and
as long as we support machines without DT, you can probably add
a trivial local patch to turn off CONFIG_OF even for machines that
are multiplatform-enabled, though I would prefer not to allow that
configuration in mainline kernels.

> > 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?
>
> Yes, I expect them to work (and be patched) until they die and this
> may take another decade ;)

Ok, makes sense. I suppose once you get to the end of that time, you
can consider permanently moving to an LTS kernel, but that only gives
you two (at most six) years of updates.

       Arnd

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: RFC Need advice on reworking gpio-ep93xx.c to DT support
  2021-03-22 22:31           ` Arnd Bergmann
  2021-03-23  6:57             ` Alexander Sverdlin
@ 2021-05-25  8:44             ` Geert Uytterhoeven
  1 sibling, 0 replies; 13+ messages in thread
From: Geert Uytterhoeven @ 2021-05-25  8:44 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Alexander Sverdlin, nikita.shubin, Hartley Sweeten, linux-gpio,
	Linus Walleij, bgolaszewski, Arnd Bergmann

On Mon, Mar 22, 2021 at 11:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
> 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

Hence you'll get about the same kernel image size increase either
by converting to DT and COMMON_CLOCK now, or by doing nothing and
booting v5.16-rc1 in six months...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-05-25  8:44 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.