- User Since
- Feb 3 2015, 4:54 AM (303 w, 6 d)
Sat, Nov 28
Mon, Nov 23
Fri, Nov 20
Wed, Nov 18
Mon, Nov 16
Perfect. Many thanks for cooperation.
Sun, Nov 15
In any case, with these minor issues fixed, LGTM
Sat, Nov 7
Thu, Nov 5
Tested on real HW without issues.
Wed, Nov 4
Tested on ARM and ARM64
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.
Tue, Nov 3
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.
Mon, Nov 2
Sun, Nov 1
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.
Sat, Oct 31
Oct 30 2020
Oct 29 2020
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:
Oct 28 2020
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 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 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."
Oct 24 2020
Oct 14 2020
Oct 11 2020
Oct 10 2020
Oct 1 2020
Sep 28 2020
Sep 27 2020
Sep 26 2020
Already committed as part of other change.
Already committed as part of other change.
Sep 25 2020
Sep 24 2020
Sep 23 2020
Sep 21 2020
tested on a problematic boards - everything works
Sep 20 2020
Sep 19 2020
Sep 18 2020
Sep 14 2020
Sep 1 2020
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?
(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.