[PATCH v8 00/22] RISC-V Kendryte K210 support improvements

[Damien Le Moal]

On 2020/12/16 10:43, Palmer Dabbelt wrote:
> On Sun, 13 Dec 2020 00:06:22 PST (-0800), Damien Le Moal wrote:
>> On Sat, 2020-12-12 at 22:04 -0800, Stephen Boyd wrote:
>>> Quoting Damien Le Moal (2020-12-10 06:02:51)
>>>>
>>>> Finally the last two patches updates the k210 nommu defconfig to include
>>>> the newly implemented drivers and provide a new default configuration
>>>> file enabling SD card support.
>>>>
>>>> A lot of the work on the device tree and on the K210 drivers come from
>>>> the work by Sean Anderson for the U-Boot project support of the K210
>>>> SoC. Sean also helped with debugging many aspects of this series.
>>>>
>>>> A tree with all patches applied is available here:
>>>> https://github.com/damien-lemoal/linux, k210-sysctl-v20 branch.
>>>> A demonstration of this series used on a SiPeed MAIX Dock
>>>> board together with an I2C servo controller can be seen here:
>>>> https://damien-lemoal.github.io/linux-robot-arm/#example
>>>>
>>>> This tree was used to build userspace busybox environment image that is
>>>> then copied onto an SD card formatted with ext2:
>>>> https://github.com/damien-lemoal/buildroot
>>>> Of note is that running this userspace environment requires a revert of
>>>> commit 2217b982624680d19a80ebb4600d05c8586c4f96 introduced during the
>>>> 5.9 development cycle. Without this revert, execution of the init
>>>> process fails. A problem with the riscv port of elf2flt is suspected but
>>>> not confirmed. I am now starting to investigate this problem.
>>>>
>>>> Reviews and comments are as always much welcome.
>>>
>>> What's the merge plan for this series? I'd like to apply the clk patches
>>> but they're combined with the sysctl driver so I guess I can't?
>>
>> Not sure. Palmer ? What is your plan for this series ? Can you queue the
>> riscv/DT pieces for 5.11 ?
>>
>> I will post a v9 to address Rob's comment on the sysctl and fpioa drivers
>> binding doc, not other with v8 changes beside that.
> 
> I guess I got hung up on that bultin DT thing, but I've sort of decided I don't
> really care that much (though I guess I didn't decide enough to reply to the
> email...).  I don't think it's 5.11 material: we were told to be stricter this
> time around because of the timing, and I'm trying to sort out a boot issue
> that's manifesting post 5.10+for-next merge so I probably won't have time to
> take more stuff.
> 
> Also: I'm kind of trying to avoid the whole thing where I take patches that
> have a bunch of versions sent either right before or during the merge window,
> as it just makes things too hard to keep track of.

OK. 5.12 it is then. Please queue these in a branch as soon as possible once the
merge window is done. Or do you prefer that I resend everything rebased on
5.11-rc first ?

That said, I think patches 1-3 should go in 5.11. 1 & 2 are trivial and patch 3
fixes a nasty bug that exists with the current k210 support.


-- 
Damien Le Moal
Western Digital Research