Samsung's Inki Dae sent another message last week to the mailing lists to target David Airlie in an attempt to achieve a response out of him. Inki was successful. David looked at the code and provided feedback. He didn't make any comments about reject the code outright based upon any missing open-source user-space driver suppot or anything else, like he has done in the past. His message commenting on Samsung's new open-source Direct Rendering Manager code is below.
I was sort of hoping someone else would take a look at these ARM drivers before me, it might be worth getting some inter-company review between the vendors submitting drm components as I'm guessing its going to be a lot of the same thing.
But I've done a quick review and some things that stick out.
1. include/drm/samsung_drm.h should only contain public information for use on the userspace ioctl interface, it shouldn't contain any kernel private data structures, they should be in drivers/gpu/drm/samsung/samsung_drv.h or something very similiar.
2. I'm not sure why samsung_drm_fn_encoder exists, it looks like from the crtc mode set functions you call the encoder mode set functions, is it not possible to use the helper drm_crtc_helper_set_mode so that the crtc mode set is called then the encoder ones without having the explicit calls? If not please either document it or point at the explaination I missed.
3. Not terribly urgent but is samsung the best name for this? what happens if you bring out another chip, I also think there is a lot of samsung_drm_ in function names that seems not that useful. dropping _drm_ might help.
4 ioctls: drm_samsung_gem_map_off needs explicit padding before the 64-bit, drm_samsung_gem_mmap needs explicit padding before the 64-bit,, though I'm not sure you need these ioctls all now that the dumb interface is upstream, what is usr_addr in the gem create ioctl for? this seems wrong, it also looks too short for 64-bit addresses, but passing in userspace addr to kernel is generally not a great plan.
5. you probably don't need master_create/set ops.
Since that message he's also exchanged several more emails on the mailing list with Inki.
It's a different story from what he's said to Qualcomm or Texas Instruments in the past when they have published similar open-source DRM driver code for their ARM SoCs. It's a similar situation to VIA's failed attempts in the past at only partially open-source graphics stacks on Linux.
Let's see what happens here and whether the Samsung DRM driver manages to make it into the mainline Linux kernel.