On 22/10/2019 00.11, Li Yang wrote: > On Mon, Oct 21, 2019 at 3:46 AM Rasmus Villemoes > <linux@xxxxxxxxxxxxxxxxxx> wrote: >> >>> Can you try the 4.14 branch from a newer LSDK release? LS1021a should >>> be supported platform on LSDK. If it is broken, something is wrong. >> >> What newer release? LSDK-18.06-V4.14 is the latest -V4.14 tag at >> https://github.com/qoriq-open-source/linux.git, and identical to the > > That tree has been abandoned for a while, we probably should state > that in the github. The latest tree can be found at > https://source.codeaurora.org/external/qoriq/qoriq-components/linux/ Ah. FYI, googling "LSDK" gives https://lsdk.github.io as one of the first hits, and (apart from itself being a github url) that says on the front page "Disaggregated components of LSDK are available in github.". But yes, navigating to the Components tab and from there to lsdk linux one does get directed at codeaurora. >> In any case, we have zero interest in running an NXP kernel. Maybe I >> should clarify what I meant by "based on commits from" above: We're >> currently running a mainline 4.14 kernel on LS1021A, with a few patches >> inspired from the NXP 4.1 branch applied on top - but also with some >> manual fixes for e.g. the pvr_version_is() issue. Now we want to move >> that to a 4.19-based kernel (so that it aligns with our MPC8309 platform). > > We also provide 4.19 based kernel in the codeaurora repo. I think it > will be helpful to reuse patches there if you want to make your own > tree. Again, we don't want to run off an NXP kernel, we want to get the necessary pieces upstream. For now, we have to live with a patched 4.19 kernel, but hopefully by the time we switch to 5.x (for some x >= 5) we don't need to supply anything other than our own .dts and defconfig. >> Yes, as I said, I wanted to try a fresh approach since Zhao >> Qiang's patches seemed to be getting nowhere. Splitting the patches into >> smaller pieces is definitely part of that - for example, the completely >> trivial whitespace fix in patch 1 is to make sure the later coccinelle >> generated patch is precisely that (i.e., a later respin can just rerun >> the coccinelle script, with zero manual fixups). I also want to avoid >> mixing the ppcism cleanups with other things (e.g. replacing some >> of_get_property() by of_property_read_u32()). And the "testing on ARM" >> part comes once I get to actually building on ARM. But there's not much >> point doing all that unless there's some indication that this can be >> applied to some tree that actually feeds into Linus', which is why I >> started with a few trivial patches and precisely to start this discussion. > > Right. I'm really interested in getting this applied to my tree and > make it upstream. Zhao Qiang, can you help to review Rasmus's patches > and comment? Thanks, this is exactly what I was hoping for. Even just getting these first rather trivial patches (in that they don't attempt to build for ARM, or change functionality at all for PPC) merged for 5.5 would reduce the amount of out-of-tree patches that we (and NXP for that matter) would have to carry. I'll take the above as a go-ahead for me to try to post more patches working towards enabling some of the QE drivers for ARM. Rasmus
