Drop two more omap3 legacy board files for v4.3 merge window

We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree.

This board has support for device tree based booting, and we've been printing warnings about the legacy booting being deprecated for a few merge cycles now. Let's attempt to remove the legacy booting for it.

The reason for removing the legacy booting support now rather than later is we can simply revert this patch if necessary if we run into some unexpected issues that are not trivial to fix for the device tree based booting.

Cc Signed-off-by: Grazvydas Ignotas <[email protected]>

Signed-off-by Tony Lindgren <[email protected]>

---
 arch/arm/mach-omap2/Makefile             |   1 -
 arch/arm/mach-omap2/board-omap3pandora.c | 633 -------------------------------
 2 files changed, 634 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/board-omap3pandora.c

Hi,

Quoted 10 lines · Tony Lindgren

We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree.

This board has support for device tree based booting, and we've been printing warnings about the legacy booting being deprecated for a few merge cycles now. Let's attempt to remove the legacy booting for it.

Quoted 4 lines

The reason for removing the legacy booting support now rather than later is we can simply revert this patch if necessary if we run into some unexpected issues that are not trivial to fix for the device tree based booting.

It seems we lose wifi, backlight, audio and usb host mainline support with this as pandora's .dts currently lacks all that stuff. That said I'm not aware of any mainline users (everyone seems to be on our "vendor" kernel), so maybe we can add those later.

Quoted 1 line

Cc Signed-off-by: Grazvydas Ignotas <[email protected]>

I have not signed this off...

Quoted 13 lines · Grazvydas Ignotas

Hi,

Quoted 10 lines · Tony Lindgren

We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree.

This board has support for device tree based booting, and we've been printing warnings about the legacy booting being deprecated for a few merge cycles now. Let's attempt to remove the legacy booting for it.

Quoted 7 lines

Quoted 4 lines

The reason for removing the legacy booting support now rather than later is we can simply revert this patch if necessary if we run into some unexpected issues that are not trivial to fix for the device tree based booting.

It seems we lose wifi, backlight, audio and usb host mainline support with this as pandora's .dts currently lacks all that stuff.

Quoted 2 lines

That said I'm not aware of any mainline users (everyone seems to be on our "vendor" kernel), so maybe we can add those later.

Hmm wifi should be easy, isn't that just libertas_sdio?

Quoted 14 lines · Tony Lindgren

Quoted 13 lines · Grazvydas Ignotas

Hi,

Quoted 10 lines · Tony Lindgren

We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree.

This board has support for device tree based booting, and we've been printing warnings about the legacy booting being deprecated for a few merge cycles now. Let's attempt to remove the legacy booting for it.

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

The reason for removing the legacy booting support now rather than later is we can simply revert this patch if necessary if we run into some unexpected issues that are not trivial to fix for the device tree based booting.

It seems we lose wifi, backlight, audio and usb host mainline support with this as pandora's .dts currently lacks all that stuff.

More on that later on, but a question on the vendor kernel first..

Quoted 2 lines

Quoted 2 lines

That said I'm not aware of any mainline users (everyone seems to be on our "vendor" kernel), so maybe we can add those later.

What all is keeping people from using mainline kernel on pandora? Is it the sgx or are there other reasons too remaining?

Quoted 1 line

Hmm wifi should be easy, isn't that just libertas_sdio?

Nope wl1251, we can initialize with pdata-quirks.c for now if it does not yet support device tree except for the SPI version. The same goes for the other devices too if needed, I'd assume the the EHCI is similar to beagle though.

And of course we can still wait on removing the pandora board file if you want to. Sounds like that may not be needed though because of people using "vendor" kernel in this case even with the legacy booting?

Regards,

Tony

Quoted 23 lines · Tony Lindgren

Quoted 14 lines · Tony Lindgren

Quoted 13 lines · Grazvydas Ignotas

Hi,

Quoted 10 lines · Tony Lindgren

We've been moving all omap2+ based systems to boot in device tree only mode for a few years now. Only omap3 has legacy booting support remaining. Most omap3 boards already have related arch/arm/boot/*.dts* files for booting with device tree.

This board has support for device tree based booting, and we've been printing warnings about the legacy booting being deprecated for a few merge cycles now. Let's attempt to remove the legacy booting for it.

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

The reason for removing the legacy booting support now rather than later is we can simply revert this patch if necessary if we run into some unexpected issues that are not trivial to fix for the device tree based booting.

It seems we lose wifi, backlight, audio and usb host mainline support with this as pandora's .dts currently lacks all that stuff.

Quoted 7 lines

More on that later on, but a question on the vendor kernel first..

Quoted 2 lines

Quoted 2 lines

That said I'm not aware of any mainline users (everyone seems to be on our "vendor" kernel), so maybe we can add those later.

What all is keeping people from using mainline kernel on pandora? Is it the sgx or are there other reasons too remaining?

There are multiple things, besides SGX:
- lack of 1GHz support due to lack of ABB/AVS. Meanwhile we have been running all pandoras at 1GHz for years without ABB/AVS on our kernel and no problems have been reported by users.
- overclocking support. It seems most DM3730s can do 1.2GHz and all can do 1.1GHz, running the device at that clock noticeably speeds up things, so we provide that functionality out of the box. No instances of SoC damage were reported over the years.
- using aufs for software packages, aufs wasn't merged and probably will never be
- keypad Fn key handling in the driver to simulate hardware Fn (not allowed in mainline)
- lack of driver for analog nubs

That said there probably are some people who can live without the above and prefer new features of new mainline kernels.

Quoted 6 lines

Quoted 1 line

Hmm wifi should be easy, isn't that just libertas_sdio?

Nope wl1251, we can initialize with pdata-quirks.c for now if it does not yet support device tree except for the SPI version. The same goes for the other devices too if needed, I'd assume the the EHCI is similar to beagle though.

Yeah maybe I should try to come up with a patch...

Quoted 4 lines

And of course we can still wait on removing the pandora board file if you want to. Sounds like that may not be needed though because of people using "vendor" kernel in this case even with the legacy booting?

Yes if it interferes with other mainline work just go ahead and remove it.

I think we can drop these now. This just leaves n900 and ldp with n900 pending patches for legacy proc support.

Hi,

Quoted 2 lines · Tony Lindgren

I think we can drop these now. This just leaves n900 and ldp with n900 pending patches for legacy proc support.

So I guess n900 board file removal depends on the atag procfs support in DT. What's the problem with ldp? Its DT file seem to cover everything in the board file. I guess both of them will finally be removed in 4.4?