@zeising could you merge the github MR and roll a new release please ?
The review could be updated after that.
Thanks.

In D23696#520296, @manu wrote:

In D23696#520295, @jbeich wrote:

In D23696#520294, @manu wrote:

In D23696#520283, @jbeich wrote:

Stalled until someone can reproduce the original issue. I dogfood XDG_RUNTIME_DIR=/var/run/$USER on tmpfs(5). Sway works fine even after changing XDG_RUNTIME_DIR to point to a directory on ZFS

With your patches you mean ?

Without the hack and my patches from here. However, I can't rely on my QA alone as I have a number of patches against kernel/userland/ports/etc.

Ok, I'll try on my machine.

In D23696#520295, @jbeich wrote:

In D23696#520294, @manu wrote:

In D23696#520283, @jbeich wrote:

Stalled until someone can reproduce the original issue. I dogfood XDG_RUNTIME_DIR=/var/run/$USER on tmpfs(5). Sway works fine even after changing XDG_RUNTIME_DIR to point to a directory on ZFS

With your patches you mean ?

Without the hack and my patches from here. However, I can't rely on my QA alone as I have a number of patches against kernel/userland/ports/etc.

In D23696#520283, @jbeich wrote:

Stalled until someone can reproduce the original issue. I dogfood XDG_RUNTIME_DIR=/var/run/$USER on tmpfs(5). Sway works fine even after changing XDG_RUNTIME_DIR to point to a directory on ZFS

Looks promising, let's wait a bit for upstream to at least ack the patches.

Yeah Niclas directed me to the meson lines WRT wayland.
LGTM.

Approved-by: manu (mentor)

I'm not super familiar with this lib and how it works but we compile it with --disable-wayland so I'm wondering why this swich is set and how it worked for you. Could you explain more on this ?
Otherwise patch looks good to me.

Build finished, tested ok with sway so I think we're good to go.

LGTM
I've started a build to test on my laptops later today.
ping @zeising for x11 approval.

LGTM

In D23649#519079, @tobik wrote:

Just commit trivial stuff like this.

Note that we also use dtb from the rpi-firmware package for RPI* board.

I do import DTS files by bulk.
I'll deal with 5.5 import next week.

Thanks, works great now.

Tested with both /dev/drm/0 and /dev/dri/card0 (which is a link to /dev/drm/0) and fdevname just returns "drm".
Which is better than NULL but mostly useless for libdrm use case.
But that might be the way those dev are created in drm-kmod.

LGTM

In D23085#509098, @hselasky wrote:

Probably I asked already, but can the DRMKPI be used at the same time another driver is using the LinuxKPI?

In D23085#505971, @hselasky wrote:

OK, I'll see if I can spend some time tomorrow to look at the code. Thank you!

No plan to update this now.

No plan to update this now.

No plan to update this now.

No plan to update this anymore.

outdated

Changes will be made to the rk805 driver instead.

In D22060#508773, @skibo wrote:

I'll look into submitting the fix to u-boot but it won't appear until 2020.04.

In D22060#508475, @lwhsu wrote:

This is pity that this patch get abandoned. If this patch fixes the issue, we can certainly readd these ports. @skibo and @manu , are you still interested in checking this?

In D23093#507777, @ian wrote:

What kind of flags go into the flags arg? I suspect the quick answer is GPIO flags. The more complete answer is probably "some subset of gpio flags which differs from one device to another". That leads to the question of what to do on an attempt to set multiple flags where some are supported and some aren't.

In D23145#507269, @kevans wrote:

In D23145#507267, @manu wrote:

In D23145#507266, @bz wrote:

If it were to become a "generic" function, where would we put it?

No idea :)

I'd be tempted to stick such a thing in ^/sys/dev/fdt/fdt_common.c, since it's (edit: not) hooking much into ethernet stuff -- just determining a MAC address to use for a given node.

In D23145#507266, @bz wrote:

In D23145#507260, @manu wrote:

The bindings (https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L16) seems to indicate
that mac-address should be used if it exists and is prefered to local-mac-address.
Maybe change dwc_get_hwaddr_fdt to handle that and make it a generic helper ?

Should we support both as USB does here? https://svnweb.freebsd.org/base/head/sys/dev/usb/usb_fdt_support.c?annotate=347974#l100

The bindings (https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L16) seems to indicate
that mac-address should be used if it exists and is prefered to local-mac-address.
Maybe change dwc_get_hwaddr_fdt to handle that and make it a generic helper ?

In D23085#506688, @greg_unrelenting.technology wrote:

We simply have slightly different conditions a so we must take drmkpi as adaptation, not emulation, layer.

Why not keep the emulation for everything that's already in linuxkpi/drm-kmod, while adding adaptation for the FDT stuff and other missing parts?!

LGTM.
Not sure about the LDO3 patch, I don't see it used on the schematics (http://dl.cubieboard.org/model/CubieBoard1/Hardware/cubieboard_schematic_2012-08-08.pdf)

In D23085#506311, @hselasky wrote:

Can you use the port-drm driver at the same time as base DRM? Some people use PCI graphics adapters with ARM.

In D23085#506309, @zeising wrote:

Is the ports drm graphics drivers intended to be switched over to this framework, or is it only for ARM kernel drivers?

Handle clock errors.

Use the new fdt_pinctrl methods.

In D23085#505975, @bcr wrote:

Do you need any specific actions from the core team or was core only added as reviewer because Phabricator tried to be smart (too much mention of the word "core" in a different context)?
Let us know if we need to discuss/decide something.

I've pushed some change here : https://github.com/evadot/freebsd/commits/drm_arm_v5.4-rebase-linuxkpi

In D23085#505947, @hselasky wrote:

That might be a good solution yes.
For now this doesn't work as a module, the main reason is that I could never make my drm driver works as a module for a few reasons :

Doesn't matter. Just make corresponding kernel options, like the existing COMPAT_LINUXKPI .
options COMPAT_LINUXKPI_BASE
options COMPAT_LINUXKPI_NET
options COMPAT_LINUXKPI_DRM
...
and so on.

In D23085#505946, @hselasky wrote:

Is it possible to add this driver as part of the existing KMS DRM driver?

What do you mean ?

I mean as a part of https://github.com/FreeBSDDesktop/kms-drm .
--HPS

In D23085#505943, @hselasky wrote:

Also keep in mind that we can split out network related functions from the LinuxKPI, in an own linuxkpi_net .
Like:
linuxkpi_base.ko
linuxkpi_net.ko
linuxkpi_drm.ko
linuxkpi_gplv2.ko
and so on.
This would be the right approach forward.

In D23085#505942, @hselasky wrote:

In D23085#505935, @manu wrote:

In D23085#505934, @hselasky wrote:

drmkpi/ : A somewhat stripped down copy of linuxkpi The reasons for having a copy are :
The full linuxkpi is usefull for importing drivers from Linux, but for FreeBSD drivers it adds some useless stuff like a linux_dev for each device.

I really don't like this.
How many are the differences?
The currently layout of sys/compat/linuxkpi , was exactly made so that you could overlay different versions of LinuxKPI, having one base LinuxKPI. We should try to build on that. Your approach likely also breaks the kernel linker, which currently doesn't care if you have multiple symbols with same name. What happens if you load drmkpi and linuxkpi at the same time?
Please integrate drmkpi within the sys/compat/linuxkpi folder, like this:

1) Create sys/compat/linuxkpi/basedrm/xxxx  include and src
2) use #include_next <> where approprate.

--HPS

That would mean creating a .h for every file but I guess this is cleaner, I'll have a look at this.

If the files are identical, then you don't need any wrapper, using include "basedrm" first, then "common" afterwards.