Well one of these boards are still on my desk, but I guess I could have a local config for it as we are using it for development only

I am fine with mechanical convert of APIs in this driver

context

fix !FDT build

Use 48-bit address space regardless of VAX bit

set maxaddr correctly in tag and domain->end

it does not seem to work with 52 bit

+       if (sc->features & SMMU_FEATURE_VAX)
+               iodom->end = MAXADDR_52BIT;
+       else
+               iodom->end = MAXADDR_48BIT;

ARM Doorbell:

Forgot to re-generate patch

Address Manu's comments on ARM Doorbell:
o Release resources on detach
o Free cells in error paths
o Remove unneeded M_DOORBELL

Move MMIO-SRAM device to dev/sram. Add SCMI related devices to config.

In D37316#857228, @manu wrote:

Still thinks that mmio_sram should be elsewhere, it's not firmware related and not arm (tm) specific.

Fix "optional" arguments.

Address @manu's comments. Thanks!

In D37316#856924, @br wrote:

In D37316#855385, @manu wrote:

I don't think that this should live under sys/arm64/scmi.
I have sys/dev/firmware/xilinx coming soon-ish, and I think that all firmware related drivers should be under sys/dev/firmware so maybe put this under sys/dev/firmware/arm/

That directory contains 23-25 y.o. source code and a README file for FreeBSD 5x.
@andrew what do you think where SCMI code should live ?

In D37316#855385, @manu wrote:

I don't think that this should live under sys/arm64/scmi.
I have sys/dev/firmware/xilinx coming soon-ish, and I think that all firmware related drivers should be under sys/dev/firmware so maybe put this under sys/dev/firmware/arm/

The stratix10 drivers has to be updated to use ofw_firmware bus instead of firmware bus in DRIVER_MODULE macroses.

o Fix length check;
o Switch to ofw_firmware bus.

Seems to work fine on ARM Morello:

o Make in_buf const;
o Remove unneeded casts;
o use len from OF_getencprop_alloc_multi().
o Remove firmware.c changes due to new firmware driver.

Restore firmware.c change.

Change in/out buf data types.
Remove unrelated code from files.arm64.

o Remove perf protocol for now.
o Rewrite protocols.h.
o Rename doorbell.c to arm_doorbell.c, mmio.c to mmio_sram.c

In D37325#849561, @mmel wrote:

I don't think this feature is appropriate for a generic layer. Practically no physical clock can implement it. A PLL can typically produce trillions of discrete frequencies, which makes it practically impossible to enumerate.

IMHO you should add it to scmi_clknode_methods as a custom function (with an appropriate prefix ) Simply create an .m file for the method definition and add this new method to the method table.

In D37316#848047, @andrew wrote:

I think the extres changes should be split out to a new file.

Can you add scmi_ to the start of all the scmi files. The build system puts all the .o files in the same directory so we need to make sure the source files have a unique name.

Use MAX_SETTINGS macro from cpu.h.
Split-out extres/clk changes.

add a check

In D36394#826604, @manu wrote:

In D36394#826540, @br wrote:

In D36394#826539, @emaste wrote:

We don't have ums on amd64 either

I don't have any objection but it should be loaded automatically when a USB mouse is found?

My situation was that I have updated kernel, then noticed mouse is not working anymore.
I spent a day looking for a bug in DRM and purecap user graphical stack. Eventually found that my kernel driver module for mouse is not compatible with new kernel.

Because you didn't recompiled the modules perhaps ?
This is expected on current for any modules.
I don't see why we should include ums in GENERIC, we already have too much stuff.

In D36394#826539, @emaste wrote:

We don't have ums on amd64 either

I don't have any objection but it should be loaded automatically when a USB mouse is found?

In D35130#810258, @dougm wrote:

Will this be RFC'ed?

In D35487#804790, @alc wrote:

In D35487#804780, @br wrote:

The idea of these wrappers was to abstract function names, i.e. make them looking generic by removing name "gas". I'm not sure what "gas" stands for, but there is no such thing on arm64.

I believe that it stood for "guest address space".

I also considered renaming iommu_gas_map, etc. to iommu_map, etc., but that entailed more changes. Nonetheless, I would be happy to take that approach.

so with this I can use iommu_map() in my ARM Komeda display controller driver (part of cheribsd), not confusing anyone with 'gas'

The idea of these wrappers was to abstract function names, i.e. make them looking generic by removing name "gas". I'm not sure what "gas" stands for, but there is no such thing on arm64.

In D35424#803934, @alc wrote:

In D35424#803847, @andrew wrote:

Do we need the offset? We just need a mapping for the physical page the vm_page_t points to.

From what you've written, I would say, "No." We can simply pass 0 as the offset. Can you verify that the current patch works?

rename PCI_ID_IOMMU to PCI_ID_OWF_IOMMU

remove committed part

Reuse pci_get_id() method, just add IOMMU id type.

context added

Remove cdns_i2c from files

In D34262#775530, @andrew wrote:

Where did this come from? (i.e. which git tree).

Are we expecting to continue development in FreeBSD, or should it be considered contrib code & be a vendor import?

good job

Fix typo.

Collect all PPIs since they indeed could be different on different CPUs

Fix bug: Initialize cpuid to -1.
Also for PPI we need just one resource, so stop iteration over ACPI tables if PMU PPI interrupt found.

In D24423#737819, @andrew wrote:

Was it intentional you reverted MAX_RLEN back to 8?