Removing partially supported SoCs

[Andrew Turner]

On Mon, 16 Jun 2014 09:59:14 +0100
Andrew Turner <andrew at fubar.geek.nz> wrote:

> I'm looking at removing support for SoCs where we have code but nobody
> appears to be supporting it. Having this extra code means we have to
> update it, but are unable to test the changes as it may not boot.
> 
> To begin with I'm planning on removing Tegra 2 and OMAP3 code.
> 
> The Tegra 2 is quite old and, as far as I know, never got to single
> user mode. There is only one kernel config that builds the code.
> Along with this the SoC dependent code is very minimal as it only
> includes what appears to be the minimum code to build and start
> booting the kernel.
> 
> For OMAP3 we don't have the std.omap3 or files.omap3 files, and
> therefore no kernel config. The omap3 directory only contains a file
> with the SoC specific register addresses. It also makes other Ti
> drivers more comples as they need to check which SoC they are running
> on.
> 
> Removing OMAP3 will not affect the other Ti SoCs, i.e. OMAP4 and
> AM35xx.
> 
> If anyone feels they wish to keep support for either of these SoCs
> they will need to work to improve the support of both getting the SoC
> booting to a useful state, and to help keep the code up to date with
> other kernel changes, i.e. to not leave when the SoC is booting to
> multi-user mode.
> 
> If I get no complaints I'm planning on removing them this weekend.
> After this other SoCs will be evaluated to determine if we should
> still support them.

I've had a little intrest in the OMAP3 support for the BeagleBoard-xM
and Gumstix Overo boards. I will leave it in for now and remove only
the Tegra 2 code.

For people interested in either of these boards, or another OMAP3 board
I would suggest you start working on bringing the support up to a level
where we can boot on these boards otherwise the code will come up for
removal again.

Andrew