[RFC] cleanup mach-s5p*

[RFC] cleanup mach-s5p*

[Kukjin Kim]

Hi all,

I have a plan to remove supporting following SoCs in mainline in the near
future.
- s5pc100 - smdkc100
- s5pv210(s5c110) - aquial, goni, smdkc110, smdkv210, torbreck
- s5p64x0(s5p6440, s5p6450)- smdk6440, smdk6450

I think users don't seem to use that any more with mainline. If so, we are
able to consider, it is not right now though.

How do you think?

- Kukjin

[RFC] cleanup mach-s5p*

[Kukjin Kim]

Hi all,

I have a plan to remove supporting following SoCs in mainline in the near
future.
- s5pc100 - smdkc100
- s5pv210(s5c110) - aquial, goni, smdkc110, smdkv210, torbreck
- s5p64x0(s5p6440, s5p6450)- smdk6440, smdk6450

I think users don't seem to use that any more with mainline. If so, we are
able to consider, it is not right now though.

How do you think?

- Kukjin

Re: [RFC] cleanup mach-s5p*

[Marek Szyprowski]

Hi Kukjin,

On 8/26/2013 2:52 AM, Kukjin Kim wrote:
> Hi all,
>
> I have a plan to remove supporting following SoCs in mainline in the near
> future.
> - s5pc100 - smdkc100
> - s5pv210(s5c110) - aquial, goni, smdkc110, smdkv210, torbreck
> - s5p64x0(s5p6440, s5p6450)- smdk6440, smdk6450
>
> I think users don't seem to use that any more with mainline. If so, we are
> able to consider, it is not right now though.
>
> How do you think?

I am against removing support for S5PC110/S5PV210. We still use it for some
of our internal development. DT support patches will be posted soon (pinctrl
and clocks). Support for S5PC100 can be easily added the same way (we also
have DT patches almost ready). S5PV210, S5PC100 and the older S3C64xx can
all be handled by the same Samsung-DT 'machine file'.

However we don't have any s5p64x0 based boards to develop DT support for
them.

Best regards
-- 
Marek Szyprowski
Samsung R&D Institute Poland

[RFC] cleanup mach-s5p*

[Marek Szyprowski]

Hi Kukjin,

On 8/26/2013 2:52 AM, Kukjin Kim wrote:
> Hi all,
>
> I have a plan to remove supporting following SoCs in mainline in the near
> future.
> - s5pc100 - smdkc100
> - s5pv210(s5c110) - aquial, goni, smdkc110, smdkv210, torbreck
> - s5p64x0(s5p6440, s5p6450)- smdk6440, smdk6450
>
> I think users don't seem to use that any more with mainline. If so, we are
> able to consider, it is not right now though.
>
> How do you think?

I am against removing support for S5PC110/S5PV210. We still use it for some
of our internal development. DT support patches will be posted soon (pinctrl
and clocks). Support for S5PC100 can be easily added the same way (we also
have DT patches almost ready). S5PV210, S5PC100 and the older S3C64xx can
all be handled by the same Samsung-DT 'machine file'.

However we don't have any s5p64x0 based boards to develop DT support for
them.

Best regards
-- 
Marek Szyprowski
Samsung R&D Institute Poland

Re: [RFC] cleanup mach-s5p*

[Arnd Bergmann]

On Monday 26 August 2013 13:54:59 Marek Szyprowski wrote:
> Hi Kukjin,
> 
> On 8/26/2013 2:52 AM, Kukjin Kim wrote:
> > Hi all,
> >
> > I have a plan to remove supporting following SoCs in mainline in the near
> > future.
> > - s5pc100 - smdkc100
> > - s5pv210(s5c110) - aquial, goni, smdkc110, smdkv210, torbreck
> > - s5p64x0(s5p6440, s5p6450)- smdk6440, smdk6450
> >
> > I think users don't seem to use that any more with mainline. If so, we are
> > able to consider, it is not right now though.
> >
> > How do you think?
> 
> I am against removing support for S5PC110/S5PV210. We still use it for some
> of our internal development. DT support patches will be posted soon (pinctrl
> and clocks). Support for S5PC100 can be easily added the same way (we also
> have DT patches almost ready). S5PV210, S5PC100 and the older S3C64xx can
> all be handled by the same Samsung-DT 'machine file'.
> 
> However we don't have any s5p64x0 based boards to develop DT support for
> them.

I agree regarding s5pv210 -- there are multiple real boards supported
besides the smdk development boards, so it would be a regression to lose
those.

For s5pc100 and s5p64x0, the kernel currently only supports the smdk
board, which is not meant for production use as far as I know, so I would
not be too sad to see them gone. I guess converting them to DT would
however make it possible to use other boards without changes in the
kernel, which does sound useful if other boards exist.

Marek, can you give some insight into what hardware you are using?
Do you in fact use the smdkc100 or are you interested in adding support
for other boards?

Speaking in more general terms, the rule we usually apply is that any
hardware that people are still interested in using stays supported
in mainline, but if the current maintainer isn't interested in dealing
with them any more, it's up to whoever wants to keep them alive to
ensure they don't hold up progress in other areas.

	Arnd

[RFC] cleanup mach-s5p*

[Arnd Bergmann]

On Monday 26 August 2013 13:54:59 Marek Szyprowski wrote:
> Hi Kukjin,
> 
> On 8/26/2013 2:52 AM, Kukjin Kim wrote:
> > Hi all,
> >
> > I have a plan to remove supporting following SoCs in mainline in the near
> > future.
> > - s5pc100 - smdkc100
> > - s5pv210(s5c110) - aquial, goni, smdkc110, smdkv210, torbreck
> > - s5p64x0(s5p6440, s5p6450)- smdk6440, smdk6450
> >
> > I think users don't seem to use that any more with mainline. If so, we are
> > able to consider, it is not right now though.
> >
> > How do you think?
> 
> I am against removing support for S5PC110/S5PV210. We still use it for some
> of our internal development. DT support patches will be posted soon (pinctrl
> and clocks). Support for S5PC100 can be easily added the same way (we also
> have DT patches almost ready). S5PV210, S5PC100 and the older S3C64xx can
> all be handled by the same Samsung-DT 'machine file'.
> 
> However we don't have any s5p64x0 based boards to develop DT support for
> them.

I agree regarding s5pv210 -- there are multiple real boards supported
besides the smdk development boards, so it would be a regression to lose
those.

For s5pc100 and s5p64x0, the kernel currently only supports the smdk
board, which is not meant for production use as far as I know, so I would
not be too sad to see them gone. I guess converting them to DT would
however make it possible to use other boards without changes in the
kernel, which does sound useful if other boards exist.

Marek, can you give some insight into what hardware you are using?
Do you in fact use the smdkc100 or are you interested in adding support
for other boards?

Speaking in more general terms, the rule we usually apply is that any
hardware that people are still interested in using stays supported
in mainline, but if the current maintainer isn't interested in dealing
with them any more, it's up to whoever wants to keep them alive to
ensure they don't hold up progress in other areas.

	Arnd

Re: [RFC] cleanup mach-s5p*

[Tomasz Figa]

Hi Kukjin,

On Monday 26 of August 2013 09:52:47 Kukjin Kim wrote:
> Hi all,
> 
> I have a plan to remove supporting following SoCs in mainline in the
> near future.
> - s5pc100 - smdkc100

We already have this almost moved to device tree. A common clock framework 
and pin control drivers should be posted soon. Supporting this platform 
should be reasonably easy, as it has a lot in common with other SoCs like 
S3C64xx and S5PV210.

> - s5pv210(s5c110) - aquial, goni, smdkc110, smdkv210, torbreck

We already have support for device tree for this in our internal tree. 
Some RFC patches have been already posted by Mateusz Krawczuk. We intend 
to mostly support Aquila and Goni as they are the platforms we are still 
using for our work.

I also have plans to add support for FriendlyARM's {Mini,Tiny}210 board 
series, which would just translate to adding appropriate board dts files. 
It's also worth noting that S5PV210 (FriendlyARM's board specifically) is 
being supported by Pengutronix in their Barebox bootloader [1][2].

I'd be all for completely dropping legacy board files of this platform and 
others mentioned in this thread, though.

> - s5p64x0(s5p6440, s5p6450)- smdk6440, smdk6450

I haven't seen any hardware on this platform myself. As Marek said, we 
don't have any boards to test mainline support on it and I'm not aware of 
any interested users. This is probably the primary candidate to be 
dropped.

My personal addition to the above list would be:

 - unused boards based on s3c64xx

I'm yet to investigate which ones are virtually dead today. The active 
ones that I would want to be kept are Cragganmore, Mini6410 and both SMDK 
boards. They are going to be moved to DT, though. AFAIK mach-ncp could be 
safely dropped, as from what I know, it isn't used anymore.

> I think users don't seem to use that any more with mainline. If so, we
> are able to consider, it is not right now though.
> 
> How do you think?

Well, if we could drop legacy board file support for them and keep them as 
DT only, support for them could be reasonably simple. Basically the code 
in arch/arm would be limited to a single .c file per SoC (e.g. mach-
s5pv210-dt.c), a bunch of SoC-level .dtsi files and a bunch of board dts 
files.

IMHO the best thing we could do would be creating a single mach-samsung, 
where all the DT-only platforms could be located, including Exynos after 
some remaining consolidation.

Best regards,
Tomasz

[1]
http://barebox.org/index.html

[2]
http://git.pengutronix.de/?p=barebox.git;a=tree;f=arch/arm/boards/friendlyarm-tiny210;h=ee3306d5e6770b8e6568fb58e9e1824cfe59fbce;hb=HEAD

[RFC] cleanup mach-s5p*

[Tomasz Figa]

Hi Kukjin,

On Monday 26 of August 2013 09:52:47 Kukjin Kim wrote:
> Hi all,
> 
> I have a plan to remove supporting following SoCs in mainline in the
> near future.
> - s5pc100 - smdkc100

We already have this almost moved to device tree. A common clock framework 
and pin control drivers should be posted soon. Supporting this platform 
should be reasonably easy, as it has a lot in common with other SoCs like 
S3C64xx and S5PV210.

> - s5pv210(s5c110) - aquial, goni, smdkc110, smdkv210, torbreck

We already have support for device tree for this in our internal tree. 
Some RFC patches have been already posted by Mateusz Krawczuk. We intend 
to mostly support Aquila and Goni as they are the platforms we are still 
using for our work.

I also have plans to add support for FriendlyARM's {Mini,Tiny}210 board 
series, which would just translate to adding appropriate board dts files. 
It's also worth noting that S5PV210 (FriendlyARM's board specifically) is 
being supported by Pengutronix in their Barebox bootloader [1][2].

I'd be all for completely dropping legacy board files of this platform and 
others mentioned in this thread, though.

> - s5p64x0(s5p6440, s5p6450)- smdk6440, smdk6450

I haven't seen any hardware on this platform myself. As Marek said, we 
don't have any boards to test mainline support on it and I'm not aware of 
any interested users. This is probably the primary candidate to be 
dropped.

My personal addition to the above list would be:

 - unused boards based on s3c64xx

I'm yet to investigate which ones are virtually dead today. The active 
ones that I would want to be kept are Cragganmore, Mini6410 and both SMDK 
boards. They are going to be moved to DT, though. AFAIK mach-ncp could be 
safely dropped, as from what I know, it isn't used anymore.

> I think users don't seem to use that any more with mainline. If so, we
> are able to consider, it is not right now though.
> 
> How do you think?

Well, if we could drop legacy board file support for them and keep them as 
DT only, support for them could be reasonably simple. Basically the code 
in arch/arm would be limited to a single .c file per SoC (e.g. mach-
s5pv210-dt.c), a bunch of SoC-level .dtsi files and a bunch of board dts 
files.

IMHO the best thing we could do would be creating a single mach-samsung, 
where all the DT-only platforms could be located, including Exynos after 
some remaining consolidation.

Best regards,
Tomasz

[1]
http://barebox.org/index.html

[2]
http://git.pengutronix.de/?p=barebox.git;a=tree;f=arch/arm/boards/friendlyarm-tiny210;h=ee3306d5e6770b8e6568fb58e9e1824cfe59fbce;hb=HEAD

Re: [RFC] cleanup mach-s5p*

[Arnd Bergmann]

On Tuesday 27 August 2013 02:08:16 Tomasz Figa wrote:
> 
> Well, if we could drop legacy board file support for them and keep them as 
> DT only, support for them could be reasonably simple. Basically the code 
> in arch/arm would be limited to a single .c file per SoC (e.g. mach-
> s5pv210-dt.c), a bunch of SoC-level .dtsi files and a bunch of board dts 
> files.

Sounds good.

> IMHO the best thing we could do would be creating a single mach-samsung, 
> where all the DT-only platforms could be located, including Exynos after 
> some remaining consolidation.

Yes, that seems like a reasonable goal for the long run. I guess the best
way to get there might be to move the s5pxxxx platforms into mach-exynos
one by one and make sure they can coexist in a multiplatform kernel.
Consolidating s3c24xx and exynos into a single platform is less interesting
because they won't run the same kernel anyway, but I also don't see any
reason against doing it. Not sure how s3c64xx would fit in then, since
it's ARMv6 but somewhat closer to the s3c24xx code base than to exynos.

	Arnd

[RFC] cleanup mach-s5p*

[Arnd Bergmann]

On Tuesday 27 August 2013 02:08:16 Tomasz Figa wrote:
> 
> Well, if we could drop legacy board file support for them and keep them as 
> DT only, support for them could be reasonably simple. Basically the code 
> in arch/arm would be limited to a single .c file per SoC (e.g. mach-
> s5pv210-dt.c), a bunch of SoC-level .dtsi files and a bunch of board dts 
> files.

Sounds good.

> IMHO the best thing we could do would be creating a single mach-samsung, 
> where all the DT-only platforms could be located, including Exynos after 
> some remaining consolidation.

Yes, that seems like a reasonable goal for the long run. I guess the best
way to get there might be to move the s5pxxxx platforms into mach-exynos
one by one and make sure they can coexist in a multiplatform kernel.
Consolidating s3c24xx and exynos into a single platform is less interesting
because they won't run the same kernel anyway, but I also don't see any
reason against doing it. Not sure how s3c64xx would fit in then, since
it's ARMv6 but somewhat closer to the s3c24xx code base than to exynos.

	Arnd