Perfect. Many thanks for cooperation.

In any case, with these minor issues fixed, LGTM

Tested on real HW without issues.

Tested on ARM and ARM64

Tested on ARM and ARM64

In D23085#604314, @greg_unrelenting.technology wrote:

I think that having one single codebase, fully based on GPL code for fast porting, is a MUCH more important goal than having display output without GPL (/in base).

Why you think that “single codebase, fully based on GPL” has any relation to fast porting in this context?
My understanding is that because the graphics on the SBC SoCs are related to virtually every subsystem, porting (and maintenance) cost increase exponentially.

The main issue in SBC DRM implementation is that graphic driver doesn’t handle separate self-contained device but it handle device tightly integrated in system, where many part of SoC are shared between GPU and rest of system. Also, graphic subsystem is not monolithic, it consist from multiple subdevices spreaded over whole SoC. some of these subdevices must be implemented by native drivers (rasterizer, HDMI formatter) we cannot condition presence of (unaccelerated) graphic console by GPL code.
Because of this we cannot use linux_device approach (we must be able to pass same struct device (or device_t) between native and ‘emulated’ code in all possible ways, same is true also for files and threads.
Number 1 for SBC is to have a working (with hotplug monitor) graphic output with a BSD license that can be used for X11 (Wayland). Acceleration 2D / 3D acceleration is optional and, in the worst case, can be performed by a GPL-licensed module.
And about DRMKPI - many goals are very different from LINUXKPI. DRMKPI is an attempt to implement some of the mostly used Linux functions or primitives used in DRM in a direct native way.
Another problem with LINUXKPI is significant namespace pollution caused by #define in the headers. I plan to make significant changes in this area. Each individual function should have the prefix linux_ <foo> defined to its original name only if the header is included in the Linux code.
For these reasons, I prefer to have separate implementations for now. Once the situation stabilizes, we can reconsider.
The problem has many threads that I am not able to express in a clear form, the problem is simply too complex. We have (unlike others) a functional (and I think usable) prototype, it needs some work before it can be committed (first it is necessary to resolve the real conflict LINUXKPI). But first we need a certain level of conclusion - no one is motivated to spread unacceptable code.
Plus, as you can see, I'm not a technical writer, so please excuse my chaotic words and sentences.
And let me not forget, this is by no means an attempt to slander LINUXKPI. But we are, although it does not seem so, in a very different situation.

I’m looking at this from perspective of presence of multiple different implementations of IOMMUs in ARM(64) world. From this point of view, I still have some problems with code partitioning, mainly in meaning of smmu_if.m.
I think that smmu_if.m should be taken as interface between system and individual IOMMU implementation. That’s mean that it should be decontaminated from using smmu (in names and/or as argument) and renamed to iommu_if.m.
The system wide function in smmu_iommu.c (like iommu_get_ctx(), iommu_find(),iommu_registe() or so) should be moved to own independent file (say iommu.c) and all HW dependent functionality should be passed by using iommu_if.m to given implementation.

I think it's wrong. In this case, multi-page alignment is required, the old comment is correct. Please see https://reviews.freebsd.org/D26735. I plan to commit this in the next day or two.

In D26975#602614, @cyprien_cypou.net wrote:

In D26975#602036, @cyprien_cypou.net wrote:

I think from GICv2 it would be assumed that the OS could write to the SGI bits. Software cannot know all existing implementations.

Andrew, I'm sorry but I don't quite understand why we crossing.
I will try to repeat my objections in a more compact/consistent form.
I have 3 objections:

In D26975#601910, @andrew wrote:

We already enable the SGIs on the non-boot CPUs in arm_gic_init_secondary and PIC_ENABLE_INTR will only be called when mp_ncpus != 1 so will be in a multicore system.

I think that calling gic_irq_mask() for SGIs is redundant and potentially dangerous, we should remove it (or eventually, make it specific only for exact GIC implementation .
The right place for doing same on boot CPU is arm_gic_attach() again only conditionally for specific version.

I'm afraid it's not that simple.

• the GICv2 architecture manual states for GICD_ISENABLE[0] this: "for SGIs the behavior of the bit on reads and writes is IMPLEMENTATION DEFINED".
• for all ARM GICs up to GIC-500 all SGIs are always enabled.
• GICD_ISENABLE[0] is declared as RO for older versions of GICs (i.e. PL390) and attempt to write to it may cause abort.
• GIC-600 have this slightly cryptic note for GICD_ISENABLE register block: "The first one of these registers does not exist when affinity routing is enabled."

Already committed as part of other change.

Already committed as part of other change.

tested on a problematic boards - everything works

Address objections

imho, also drm2 option should be moved to options.arm. otherwise, NOTES kernels may fail. I'm OK with rest

I’m slightly confused by code partitioning.
With that in mind that we have multiple types of IOMMUs (rockchip, tegra, smmu v2, allwinner …, and one SoC can have multiple different IOMMUs, I’m not sure how this patch fit in this situation.
Is iommu.c intended as base for future IOMMU independent part of framework? If yes, why it contain functions prefixed by smmu_? If not, why it’s named by generic name?
Do you have any roadmap, ideas how final (supporting multiple kinds of IOMMUs in one generic kernel) should be structured?

I think that we should fix this also for arm. Or at least we should use ‘compatible’ (with arm) way.
So if I can summarize actual status:

• PMU can have single PPI interrupt or multiple SPI interrupts (one for each core in given cluster).
• The driver must not expect that all cores are started (PSCI is free to not start a core)
• The system may have multiple PMUs (each cluster may have own - moreover with different type for big-little SoC).
• cpuid has no relation to the order of any property in DT. The only robust way how to identify right physical core is comparing its MPIDR register to expected value

Can you please add following compatibility string before commit?
https://github.com/strejda/freebsd/commit/3f9ef1815b12048dba47504ff1ce9f48cce0fac1
(tested on honeycomb board with LX2160A SOC)
In any case its OK for me, all potential MMCCAM related problems should be fixed in own commit.
Thanks for your effort.