Re: Re: Hilscher NetX mach-netx refactorings

[Linus Walleij <linus.walleij@linaro.org>]

Hi Michael!

Thanks for interacting with the community and helping us out!

On Mon, Jan 14, 2019 at 12:26 PM Michael Trensch <MTrensch@hilscher.com> wrote:

> I am working for Hilscher and responsible with my group for linux
> running on our new SoCs (netX4000 currently), due to a corporate
> guideline all public mail addresses for github projects is set to
> github@hilscher.com to distribute them to the proper department.

Fair enough, this clearly works.

> >> On a related note, there does appear to be active work on
> >> newer netx machines that were never upstreamed, see
> >> https://github.com/Hilscher/netx4000-linux/commits/v4.9-netx4000-stable
>
> This work is not combatible with the mainlined netx platform, which is
> netX100/500, but for a new netX SoC, called netX 4000.

So a pressing question is whether it is OK with Hilscher that we
decomission/delete the current support code for NetX
nxdkn, nxdb500 and nxeb500hmi? Or are these products that
still see active deployment (new designs) and maintenance
in the long term (5-10 years from now)?

> Currently we have
> not had any plans or schedule to get it mainline yet, as we needed to
> get it finished first. That does not mean we don't want it to become
> mainline. This surely depends on the number of requests that arise for
> this specific SoC.

OK! But when you have time and resources, please consider to
work with the kernel community to get the board support upstream.

> More information on the netX 4000 SoC itself can be found here:
> https://www.hilscher.com/products/product-groups/network-controller/asics/netx-4000/

This is an interesting SoC, primarily for the use of an A7 coprocessor
for an RTOS. We have seen a number of devices of this type.
You might be interested in looking into OpenAMP for the communcation
with the RTOS core. The industry has identified fragmentation in the
shared-memory (and other) AMP solutions and try to standardize that
communication around RPMSG. This is good because the Linux side
of things is very well tested and stable, and we don't get too many
deviant AMP mechanisms to deal with in the kernel.
https://www.multicore-association.org/workgroup/oamp.php

> When trying to bring it mainline, I see, at the current point, some more
> work arising, as we needed to patch some mainline sources due to some
> chip specialties like:

Trying to add my €0.05 here...

>   * nbpfaxi: static-wired-dma-channels ->
> https://github.com/Hilscher/netx4000-linux/commit/a3fb58c531caf0da1d8eba90171bc4a8ce2d1da3.
> I don't know if such a patch is legit or if it should be more universal

#ifdef is generally frowned upon and does not work with the multiplatform
paradigm (one kernel image for all, many device trees).
But certainly the DMA subsystem maintainers will help out finding
the right solution if you talk to them (they have a separate mailing
list and everything).

>   * nand specialities from a pl353 driver starting at ->
> https://github.com/Hilscher/netx4000-linux/commit/f7da2b259b71439a0c6662af8697292fe2c3afda

I was involved in reviewing a PL353 driver that was sent
by Naga Sureshkumar Relli from Xlilinx so I guess that is
what you are using? I have no idea on whether this is the
right approach for ioremap() or if that is even what you want
to do for a NAND driver. I think Naga is still working on this
rawnand driver, certainly you can be added to the reviewers
of the driver as we work with it in the community.

>   *  Device-tree files are currently hosted in yocto recipes
> (https://github.com/Hilscher/meta-hilscher-netx4000/tree/master/files/dts)
> to prevent maintenance / syncing issues on our side

These can all be merged into the kernel proper when the
platform lands upstream. I can see that your clock implementation
will probably need some changes using cells for clock type
rather than compatible, otherwise it looks pretty standard.

>   * CAN driver which is taken / ported from rza1_can ->
> https://github.com/Hilscher/netx4000-linux/commit/46ca8736f44bf8000ac41717efb77f188db1f68e
> https://github.com/Hilscher/netx4000-linux/commit/f08e62e0c114b5e8037e44979317f6e777671140

I suppose it is so similar that we can simply augment what we have
in the upstream kernel to also support your variant.

>   * Framebuffer display driver ->
> https://github.com/Hilscher/netx4000-linux/commit/ceee73345214504bf8e7c2a9124519e55e2b2b79

I would reimplement this using DRM. Simple framebuffers are
quite easy to support with DRM nowadays, see for example:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/tve200

> As already stated somewhere, the problem indeed is the missing modem
> control signals, due to pin count limitations and lack of more pin
> function multiplexers, on some uarts on this chip. That's why they need
> to be emulated via GPIOs. More or less, when it comes to delays the
> PL011s modem control line would need to be set manually as well.

We can certainly work out an "approved quirk" in the upstream kernel
to handle this given the very straight-forward usecase.
It requires some time and tinkering like everything else.

> The netX4000 platform is only built using a device tree. The device tree
> files were sometime ago moved out of the kernel into our yocto layer to
> reduce maintenance and have a single location. I know this conflicts
> with mainlining.

No big deal where you keep the files as long as they are merged
when we implement the platform in the upstream kernel.

> I don't know what needs additionally to be done for working
> multiplatform support.

I would simply look at one of the similar platform in the upstream
kernel, starting with v5.0-rc1 and following the pattern set in
presentations like these:
https://elinux.org/images/2/2a/Schulz-how-to-support-new-board-u-boot-linux.pdf
https://elinux.org/images/1/18/ARM64_SoC_Linux_Support_Check-List.pdf
https://elinux.org/images/2/26/Getting-Your-Patches-in-Mainline-Linux-What-Not-To-Do-and-a-Few-Things-You-Could-Try-Instead-Marc-Zyngier-ARM.pdf

Gregory's presentation (second) is especially helpful for a new Linux
subarchitecture specifically.

Multiplatform is generally just making sure that all system-specific
code will only run for that specific device tree that represents
your specific system. The multiplatform in this case is
ARCH_MULTI_V7.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel