[PATCH v3 1/6] rockchip: move ROCKCHIP_STIMER_BASE to Kconfig

[Johan Jonker]

On 3/12/22 15:39, Kever Yang wrote:
> Hi Johan,
>
> On 2022/3/12 18:01, Johan Jonker wrote:
>> On 3/12/22 09:51, Jagan Teki wrote:
>>> On Thu, Dec 30, 2021 at 10:18 PM Johan Jonker <jbx6244 at gmail.com> wrote:
>>>> Move ROCKCHIP_STIMER_BASE to Kconfig.
>>>>
>>>> Signed-off-by: Johan Jonker <jbx6244 at gmail.com>
>>>> ---
>>>>
>>>> Changed V3:
>>>>   add ROCKCHIP_STIMER
>>>> ---
>>>>  arch/arm/mach-rockchip/Kconfig        | 22 ++++++++++++++++++++++
>>>>  arch/arm/mach-rockchip/px30/Kconfig   |  3 +++
>>>>  arch/arm/mach-rockchip/rk3036/Kconfig |  3 +++
>>>>  arch/arm/mach-rockchip/rk3128/Kconfig |  3 +++
>>>>  arch/arm/mach-rockchip/rk322x/Kconfig |  3 +++
>>>>  arch/arm/mach-rockchip/rk3288/Kconfig |  3 +++
>>>>  arch/arm/mach-rockchip/rk3308/Kconfig | 10 ++++++----
>>>>  arch/arm/mach-rockchip/rk3328/Kconfig |  3 +++
>>>>  arch/arm/mach-rockchip/rk3368/Kconfig |  3 +++
>>>>  arch/arm/mach-rockchip/rk3399/Kconfig |  3 +++
>>>>  arch/arm/mach-rockchip/rk3568/Kconfig |  3 +++
>>>>  include/configs/px30_common.h         |  1 -
>>>>  include/configs/rk3036_common.h       |  1 -
>>>>  include/configs/rk3128_common.h       |  1 -
>>>>  include/configs/rk322x_common.h       |  1 -
>>>>  include/configs/rk3288_common.h       |  1 -
>>>>  include/configs/rk3308_common.h       |  1 -
>>>>  include/configs/rk3328_common.h       |  1 -
>>>>  include/configs/rk3368_common.h       |  1 -
>>>>  include/configs/rk3399_common.h       |  1 -
>>>>  include/configs/rk3568_common.h       |  1 -
>>>>  21 files changed, 55 insertions(+), 14 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-rockchip/Kconfig
b/arch/arm/mach-rockchip/Kconfig
>>>> index da6871eb..7a624c64 100644
>>>> --- a/arch/arm/mach-rockchip/Kconfig
>>>> +++ b/arch/arm/mach-rockchip/Kconfig
>>>> @@ -343,6 +343,28 @@ config ROCKCHIP_BOOT_MODE_REG
>>>>           The Soc will enter to different boot mode(defined in
asm/arch-rockchip/boot_mode.h)
>>>>           according to the value from this register.
>>>>
>>>> +config ROCKCHIP_STIMER
>>>> +       bool "Rockchip STIMER support"
>>>> +       default y
>>>> +       depends on (ROCKCHIP_PX30||   \
>>>> +                   ROCKCHIP_RK3036|| \
>>>> +                   ROCKCHIP_RK3128|| \
>>>> +                   ROCKCHIP_RK322X|| \
>>>> +                   ROCKCHIP_RK3288|| \
>>>> +                   ROCKCHIP_RK3308|| \
>>>> +                   ROCKCHIP_RK3328|| \
>>>> +                   ROCKCHIP_RK3368|| \
>>>> +                   ROCKCHIP_RK3399|| \
>>>> +                   ROCKCHIP_RK3568)
>>> What if we select !(SOC-Which-don't-support-stimer). I believe the
>>> condition check here is much simpler.
>> The condition would be simpler that's correct, but this patch is made
>> with rk3066 in mind and there's no ROCKCHIP_RK3066 available yet.
>> The right approach is to only include SoC's that have a specific
>> property/functionality linked to there specific config tag.
>> U-boot should be generic. And we should not have to fix all dependencies
>> all over the place when a SoC doesn't have something.
>>
>> Please advise how to support other SoC's like rk3066.

> Thanks for you hard working on this, would you mind to share what's the
> motivation for support rk3066 and MK808 board?
> RK3066 is an SoC release at 2012, which has been EOL for a long time,
> and MK808 is a product at 2013, almost 10 years ago.

One of the advantages of open source is that a manufacturer doesn't
dictate where,
when and how long a product can be used.
It's about freedom of choice. No matter how many obstacles are put in
the way.
It works in two ways. Rockchip make use of free open source for there
products.
Users can add there own ideas/support based on manufacturer sources.
If that's not your thing then join a group of monopolists for software,
but don't sabotage things here.
It's part of the game.

MK808 was one of the first products with a Rockchip SoC that hobbyists
where able
to run there own kernel on and still does, so we keep that heritage alive.

>
>
> I'm not object for enable more SoC support on the mainline, and I know
> you have spend a lot
> of time on this, I have do something like this before, but to be honest
> I don't think it's a good idea to add support for
> rk3066 on mainline now.

If Linux is able to support the full product range then U-boot can do
that too.
The last 2 years were spent with upgrading and fixing the Linux Device tree.
It would be nice if that was synced standard automatically for the
Rockchip branch on a regular base.
The more you neglect the more outdated it becomes. See rk3288 DT.

>
>

> I merge the patches from Paweł Jarosz many years ago into rockchip local
> u-boot and make it work,
> I want to make the branch support as much SoCs as possible at that time.
> But later I found there is no people to use
> it,

No wonder, no serious person would concern the Rockchip Linux and U-boot
tree a usable option given it's current state.
It's official kernel tree hasn't been updated for some while and based
on LT versions that are outdated.
Current Rockchip activity must be checked elsewhere.
Documentation and TRM's must be obtained through other sources.

https://github.com/rockchip-linux/

https://github.com/JeffyCN/rockchip_mirrors
https://github.com/Caesar-github

https://github.com/Poco-Ye/rk-datasheet

> and the U-Boot is getting more and more heavy, old SoC support is
> the one part people want to clean,
> for it always bring in more '#if, #else' or something like this clean up

Proper written code isn't a problem.
The lack of regular maintenance creates a stock pile and then wait/hope
for others to fix.
Don't blame that on a new rk3066 SoC.
With the addition of rk3066 a number of these spots are identified.
More Kconfigs must be moved. Often DT sync from Linux. Common board
TPL/SPL file fix. Nothing special.

===

Also apply subsets of a patch series when ready.
That helps to get the flow going.
Don't let people have to send them over and over again for years like
with rk3066.

===

Move all Rockchip board maintainers in one central file, so that can be
parsed be scripts.
Verify that these maintainers are still active. (See rk3288 DT)

===

Reduce the DM footprint for TPL/SPL. We know for example what TPL/SPL
sram driver to use (see dtoc) then "short cut"/"direct link"
to select the driver in use without 10k+ of DM bloat ware. It leafs us
more room for usbplug related staff for example.


> series patches, and more terrible thing is how to
> always maintain the source code works on the old hardware. I do make
> everything work for a long time at first,
> but one day my only rk3066 board is broken, and I'm not able to do it
> anymore.

The world wide web is your friend to find a replacement.
It's not an excuse for a maintainer to not add another rk3066 device to
his collection. ;)

===

As for MK808 it can live out of tree, free of limits.
For basic convenience a place inside is preferred, but not necessary.
Up to you.

Johan



>
> Thanks,
> - Kever
>> Johan
>>
>>> Jagan.