Re: [PATCH 0/7] towards QE support on ARM

On 22/10/2019 00.11, Li Yang wrote:

On Mon, Oct 21, 2019 at 3:46 AM Rasmus Villemoes
[off-list ref] wrote:

quoted

quoted

quoted

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.

quoted

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.

quoted

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