Dave Airlie [Fri, 30 Jul 2021 06:05:58 +0000 (16:05 +1000)]
Merge tag 'drm-msm-next-2021-07-28' of https://gitlab.freedesktop.org/drm/msm into drm-next
An early pull for v5.15 (there'll be more coming in a week or two),
consisting of the drm/scheduler conversion and a couple other small
series that one was based one. Mostly sending this now because IIUC
danvet wanted it in drm-next so he could rebase on it. (Daniel, if
you disagree then speak up, and I'll instead include this in the main
pull request once that is ready.)
This also has a core patch to drop drm_gem_object_put_locked() now
that the last use of it is removed.
Dave Airlie [Fri, 30 Jul 2021 04:51:22 +0000 (14:51 +1000)]
Merge tag 'drm-misc-next-2021-07-29' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v5.15:
UAPI Changes:
- Add modifiers for arm fixed rate compression.
Cross-subsystem Changes:
- Assorted dt binding fixes.
- Convert ssd1307fb to json-schema.
- Update a lot of irc channels to point to OFTC, as everyone moved there.
- Fix the same divide by zero for asilantfb, kyro, rivafb.
Core Changes:
- Document requirements for new atomic properties.
- Add drm_gem_fb_(begin/end)_cpu_access helpers, and use them in some drivers.
- Document drm_property_enum.value for bitfields.
- Add explicit _NO_ for MIPI_DSI flags that disable features.
- Assorted documentation fixes.
- Update fb_damage handling, and move drm_plane_enable_fb_damage_clips to core.
- Add logging and docs to RMFB ioctl.
- Assorted small fixes to dp_mst, master handling.
- Clarify drm lease usage.
Driver Changes:
- Assorted small fixes to panfrost, hibmc, bridge/nwl-dsi, rockchip, vc4.
- More drm -> linux irq conversions.
- Add support for some Logic Technologies and Multi-Inno panels.
- Expose phy-functionality for drm/rockchip, to allow controlling from the media subsystem.
- Add support for 2 AUO panels.
- Add damage handling to ssd1307fb.
- Improve FIFO handling on mxsfb.
- Assorted small fixes to vmwgfx, and bump version to 2.19 for the new ioctls.
- Improve sony acx424akp backlight handling.
Maxime Ripard [Wed, 7 Jul 2021 09:36:32 +0000 (11:36 +0200)]
drm/vc4: hdmi: Remove unused struct
Commit 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") removed the
references to the vc4_hdmi_audio_component_drv structure, but not the
structure itself resulting in a warning. Remove it.
Maxime Ripard [Wed, 7 Jul 2021 09:36:31 +0000 (11:36 +0200)]
drm/vc4: hdmi: Remove redundant variables
The vc4_hdmi_audio_prepare function and the functions it's calling have
in several occurences multiple dereferences of either the sample rate or
the number of channels.
It turns out that these variables are also passed through the hdmi codec
parameters structure. Convert all the users to use this structure, and
if it's used multiple times use a variable to store it instead of
dereferencing it every time.
We make the following changes to the documentation of drm leases to
make it easier to reason about their usage. In particular, we clarify
the lifetime and locking rules of lease fields in drm_master:
1. Make it clear that &drm_device.mode_config.idr_mutex protects the
lease idr and list structures for drm_master. The lessor field itself
doesn't need to be protected as it doesn't change after it's set in
drm_lease_create.
2. Add descriptions for the lifetime of lessors and leases.
3. Add an overview DOC: section in drm-uapi.rst that defines the
terminology for drm leasing, and explains how leases work and why
they're used.
Fix a bug in smu_cmn_send_msg_without_waiting() in
that this function does not need to take the
smu->message_lock mutex in order to send a message
down to the SMU. The mutex is acquired by the
caller of this function instead.
Fence driver was enabled per ring when sw init on per IP block before.
Change to enable all the fence driver at the same time after
amdgpu_device_ip_init finished.
Rename some function related to fence to make it reasonable for read.
Alex Deucher [Thu, 8 Jul 2021 20:31:10 +0000 (16:31 -0400)]
drm/amdgpu/display: add support for multiple backlights
On platforms that support multiple backlights, register
each one separately. This lets us manage them independently
rather than registering a single backlight and applying the
same settings to both.
This converts the internal backlight in the Sony ACX424AKP
driver to do it the canonical way:
- Assign the panel->backlight during probe.
- Let the panel framework handle the backlight.
- Make the backlight .set_brightness() turn the backlight
off completely if blank.
- Fix some dev_err_probe() use cases along the way.
Inside drm_is_current_master, using the outer drm_device.master_mutex
to protect reads of drm_file.master makes the function prone to creating
lock hierarchy inversions. Instead, we can use the
drm_file.master_lookup_lock that sits at the bottom of the lock
hierarchy.
drm/amd/display: Only set default brightness for OLED
[Why]
We used to unconditionally set backlight path as AUX for panels capable
of backlight adjustment via DPCD in set default brightness.
[How]
This should be limited to OLED panel only since we control backlight via
PWM path for SDR mode in LCD HDR panel.
Reviewed-by: Krunoslav Kovac <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Camille Cho <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Changes some other code to only use aux for backlight control on
OLED panels. The commit message seems to indicate that PWM should
be used for SDR mode on HDR panels. Do something similar for
backlight control in general. This may need to be revisited if and
when HDR started to get used.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1438
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213715 Reviewed-by: Roman Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Evan Quan [Wed, 21 Jul 2021 10:19:38 +0000 (18:19 +0800)]
drm/amd/pm: restore user customized OD settings properly for NV1x
The customized OD settings can be divided into two parts: those
committed ones and non-committed ones.
- For those changes which had been fed to SMU before S3/S4/Runpm
suspend kicked, they are committed changes. They should be properly
restored and fed to SMU on S3/S4/Runpm resume.
- For those non-committed changes, they are restored only without feeding
to SMU.
This version brings along following fixed:
- Guard DST_Y_PREFETCH register overflow in DCN21
- Add missing DCN21 IP parameter
- Fix PSR command version
- Add ETW logging for AUX failures
- Add ETW log to dmub_psr_get_state
- Fixed EdidUtility build errors
- Fix missing reg offset for the dmcub test debug registers
- Adding update authentication interface
- Remove unused functions of opm state query support
- Always wait for update lock status
- Refactor riommu invalidation wa
- Ensure dentist display clock update finished in DCN20
drm/amd/display: ensure dentist display clock update finished in DCN20
[Why]
We don't check DENTIST_DISPCLK_CHG_DONE to ensure dentist
display clockis updated to target value. In some scenarios with large
display clock margin, it will deliver unfinished display clock and cause
issues like display black screen.
[How]
Checking DENTIST_DISPCLK_CHG_DONE to ensure display clock
has been update to target value before driver do other clock related
actions.
Wenjing Liu [Thu, 15 Jul 2021 18:55:28 +0000 (14:55 -0400)]
drm/amd/display: remove unused functions
[why]
It has been decided that opm state query support will be dropped.
Therefore link encryption enabled and save current encryption states
won't be used anymore and there are no foreseeable usages in the future.
We will remove these two interfaces for clean up.
[why]
Previously to toggle authentication, we need to remove and
add the same display back with modified adjustment.
This method will toggle DTM state without actual hardware changes.
This is not per design and would cause potential issues in the long run.
[how]
We are creating a dedicated interface that does the same thing as
remove and add back the display without changing DTM state.
drm/vmwgfx: Be a lot more flexible with MOB limits
The code was trying to keep a strict limit on the amount of mob
memory that was used in the guest by making it match the host
settings. There's technically no reason to do that (guests can
certainly use more than the host can have resident in renderers
at the same time).
In particular this is problematic because our userspace is not
great at handling OOM conditions and running out of MOB space
results in GL apps crashing, e.g. gnome-shell likes to allocate
huge surfaces (~61MB for the desktop on 2560x1600 with two workspaces)
and running out of memory there means that the gnome-shell crashes
on startup taking us back to the login and resulting in a system
where one can not login in graphically anymore.
Instead of letting the userspace crash we can extend available
MOB space, we just don't want to use all of the RAM for graphics,
so we're going to limit it to half of RAM.
With the addition of some extra logging this should make the
"guest has been configured with not enough graphics memory"
errors a lot easier to diagnose in cases where the automatic
expansion of MOB space fails.
The code was using the old DRM logging functions, which made it
hard to figure out what was coming from vmwgfx. The newer logging
helpers include the driver name in the logs and make it explicit
which driver they're coming from. This allows us to standardize
our logging a bit and clean it up in the process.
vmwgfx is a little special because technically the hardware it's
running on can be anything from the last 12 years or so which is
why we need to include capabilities in the logs in the first
place or otherwise we'd have no way of knowing what were
the capabilities of the platform the guest was running in.
The macro has been accounting for DRM_COMMAND_BASE for a long time
now so there's no reason to still be duplicating it. Plus we were
leaving the name undefined which meant that all the DRM ioctl
warnings/errors were always listing "null" ioctl at the culprit.
This fixes the undefined ioctl name and removes duplicated code.
Rob Clark [Wed, 28 Jul 2021 01:06:18 +0000 (18:06 -0700)]
drm/msm/gem: Mark active before pinning
Mark all the bos in the submit as active, before pinning, to prevent
evicting a buffer in the same submit to make room for a buffer earlier
in the table.
Rob Clark [Wed, 28 Jul 2021 01:06:17 +0000 (18:06 -0700)]
drm/msm: Utilize gpu scheduler priorities
The drm/scheduler provides additional prioritization on top of that
provided by however many number of ringbuffers (each with their own
priority level) is supported on a given generation. Expose the
additional levels of priority to userspace and map the userspace
priority back to ring (first level of priority) and schedular priority
(additional priority levels within the ring).
Rob Clark [Wed, 28 Jul 2021 01:06:15 +0000 (18:06 -0700)]
drm/msm: Drop submit bo_list
This was only used to detect userspace including the same bo multiple
times in a submit. But ww_mutex can already tell us this.
When we drop struct_mutex around the submit ioctl, we'd otherwise need
to lock the bo before adding it to the bo_list. But since ww_mutex can
already tell us this, it is simpler just to remove the bo_list.
Rob Clark [Wed, 28 Jul 2021 01:06:14 +0000 (18:06 -0700)]
drm/msm: Conversion to drm scheduler
For existing adrenos, there is one or more ringbuffer, depending on
whether preemption is supported. When preemption is supported, each
ringbuffer has it's own priority. A submitqueue (which maps to a
gl context or vk queue in userspace) is mapped to a specific ring-
buffer at creation time, based on the submitqueue's priority.
Each ringbuffer has it's own drm_gpu_scheduler. Each submitqueue
maps to a drm_sched_entity. And each submit maps to a drm_sched_job.
Laurent Pinchart [Mon, 25 May 2020 03:18:01 +0000 (06:18 +0300)]
drm: rcar-du: Use drm_bridge_connector_init() helper
Use the drm_bridge_connector_init() helper to create a drm_connector for
each output, instead of relying on the bridge drivers doing so. Attach
the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct
them not to create a connector.
drm: rcar-du: lvds: Convert to DRM panel bridge helper
Replace the manual panel handling with usage of the DRM panel bridge
helper. This simplifies the driver, and brings support for
DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
Laurent Pinchart [Thu, 14 May 2020 01:03:07 +0000 (04:03 +0300)]
drm: bridge: dw-hdmi: Attach to next bridge if available
On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
require a video output port connected to an HDMI sink (most likely an
HDMI connector, in rare cases another bridges converting HDMI to another
protocol). For those platforms, retrieve the next bridge and attach it
from the dw-hdmi bridge attach handler.
Laurent Pinchart [Tue, 23 Mar 2021 21:50:08 +0000 (23:50 +0200)]
drm/bridge: Centralize error message when bridge attach fails
Being informed of a failure to attach a bridge is useful, and many
drivers prints an error message in that case. Move the message to
drm_bridge_attach() to avoid code duplication.
Laurent Pinchart [Tue, 23 Mar 2021 00:09:53 +0000 (02:09 +0200)]
drm: rcar-du: Shutdown the display on remove
When the device is unbound from the driver (the DU being a platform
device, this occurs either when removing the DU module, or when
unbinding the device manually through sysfs), the display may be active.
Make sure it gets shut down.
Laurent Pinchart [Tue, 23 Mar 2021 00:09:53 +0000 (02:09 +0200)]
drm: rcar-du: Don't put reference to drm_device in rcar_du_remove()
The reference to the drm_device that was acquired by
devm_drm_dev_alloc() is released automatically by the devres
infrastructure. It must not be released manually, as that causes a
reference underflow..
Laurent Pinchart [Tue, 23 Mar 2021 00:09:53 +0000 (02:09 +0200)]
drm: rcar-du: Shutdown the display on system shutdown
When the system shuts down or warm reboots, the display may be active,
with the hardware accessing system memory. Upon reboot, the DDR will not
be accessible, which may cause issues.
Implement the platform_driver .shutdown() operation and shut down the
display to fix this.
Rob Clark [Wed, 28 Jul 2021 01:06:12 +0000 (18:06 -0700)]
drm/msm: Track "seqno" fences by idr
Previously the (non-fd) fence returned from submit ioctl was a raw
seqno, which is scoped to the ring. But from UABI standpoint, the
ioctls related to seqno fences all specify a submitqueue. We can
take advantage of that to replace the seqno fences with a cyclic idr
handle.
This is in preperation for moving to drm scheduler, at which point
the submit ioctl will return after queuing the submit job to the
scheduler, but before the submit is written into the ring (and
therefore before a ring seqno has been assigned). Which means we
need to replace the dma_fence that userspace may need to wait on
with a scheduler fence.
Rob Clark [Wed, 28 Jul 2021 01:06:11 +0000 (18:06 -0700)]
drm/msm: Consolidate submit bo state
Move all the locked/active/pinned state handling to msm_gem_submit.c.
In particular, for drm/scheduler, we'll need to do all this before
pushing the submit job to the scheduler. But while we're at it we can
get rid of the dupicate pin and refcnt.
Rob Clark [Mon, 26 Jul 2021 14:46:50 +0000 (07:46 -0700)]
drm/msm: Devfreq tuning
This adds a few things to try and make frequency scaling better match
the workload:
1) Longer polling interval to avoid whip-lashing between too-high and
too-low frequencies in certain workloads, like mobile games which
throttle themselves to 30fps.
Previously our polling interval was short enough to let things
ramp down to minimum freq in the "off" frame, but long enough to
not react quickly enough when rendering started on the next frame,
leading to uneven frame times. (Ie. rather than a consistent 33ms
it would alternate between 16/33/48ms.)
2) Awareness of when the GPU is active vs idle. Since we know when
the GPU is active vs idle, we can clamp the frequency down to the
minimum while it is idle. (If it is idle for long enough, then
the autosuspend delay will eventually kick in and power down the
GPU.)
Since devfreq has no knowledge of powered-but-idle, this takes a
small bit of trickery to maintain a "fake" frequency while idle.
This, combined with the longer polling period allows devfreq to
arrive at a reasonable "active" frequency, while still clamping
to minimum freq when idle to reduce power draw.
3) Boost. Because simple_ondemand needs to see a certain threshold
of busyness to ramp up, we could end up needing multiple polling
cycles before it reacts appropriately on interactive workloads
(ex. scrolling a web page after reading for some time), on top
of the already lengthened polling interval, when we see a idle
to active transition after a period of idle time we boost the
frequency that we return to.
Rob Clark [Mon, 26 Jul 2021 14:43:58 +0000 (07:43 -0700)]
drm/msm: Signal fences sooner
Nothing we do to in update_fences() can't be done in an atomic context,
so move this into the GPU's irq context to reduce latency (and call
dma_fence_signal() so we aren't relying on dma_fence_is_signaled() which
would defeat the purpose).
Rob Clark [Mon, 26 Jul 2021 14:43:57 +0000 (07:43 -0700)]
drm/msm: Let fences read directly from memptrs
Let dma_fence::signaled, etc, read directly from the address that the hw
is writing with updated completed fence seqno, so we can potentially
notice that the fence is signaled sooner.
drm/dp_mst: Fix return code on sideband message failure
Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing +
selftests") added some debug code for sideband message tracing. But
it seems to have unintentionally changed the behavior on sideband message
failure. It catches and returns failure only if DRM_UT_DP is enabled.
Otherwise it ignores the error code and returns success. So on an MST
unplug, the caller is unaware that the clear payload message failed and
ends up waiting for 4 seconds for the response. Fixes the issue by
returning the proper error code.
Changes in V2:
-- Revise commit text as review comment
-- add Fixes text
Marek Vasut [Sun, 20 Jun 2021 22:49:46 +0000 (00:49 +0200)]
drm: mxsfb: Clear FIFO_CLEAR bit
Make sure the FIFO_CLEAR bit is latched in when configuring the
controller, so that the FIFO is really cleared. And then clear
the FIFO_CLEAR bit, since it is not self-clearing.
Marek Vasut [Mon, 26 Jul 2021 19:44:57 +0000 (21:44 +0200)]
drm: mxsfb: Use bus_format from the nearest bridge if present
In case there is a bridge connected to the LCDIF, use bus_format
from the bridge, otherwise behave as before and use bus_format
from the connector. This way, even if there are multiple bridges
in the display pipeline, the LCDIF will use the correct format.
Marek Vasut [Sun, 20 Jun 2021 22:47:59 +0000 (00:47 +0200)]
drm: mxsfb: Increase number of outstanding requests on V4 and newer HW
In case the DRAM is under high load, the MXSFB FIFO might underflow
and that causes visible artifacts. This could be triggered on i.MX8MM
using e.g. "$ memtester 128M" on a device with 1920x1080 panel. The
first "Stuck Address" test of the memtester will completely corrupt
the image on the panel and leave the MXSFB FIFO in odd state.
To avoid this underflow, increase number of outstanding requests to
DRAM from 2 to 16, which is the maximum. This mitigates the issue
and it can no longer be triggered.
Marek Vasut [Sun, 20 Jun 2021 22:47:01 +0000 (00:47 +0200)]
drm: mxsfb: Enable recovery on underflow
There is some sort of corner case behavior of the controller,
which could rarely be triggered at least on i.MX6SX connected
to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS
bridged 1920x1080 panel (and likely on other setups too), where
the image on the panel shifts to the right and wraps around.
This happens either when the controller is enabled on boot or
even later during run time. The condition does not correct
itself automatically, i.e. the display image remains shifted.
It seems this problem is known and is due to sporadic underflows
of the LCDIF FIFO. While the LCDIF IP does have underflow/overflow
IRQs, neither of the IRQs trigger and neither IRQ status bit is
asserted when this condition occurs.
All known revisions of the LCDIF IP have CTRL1 RECOVER_ON_UNDERFLOW
bit, which is described in the reference manual since i.MX23 as
"
Set this bit to enable the LCDIF block to recover in the next
field/frame if there was an underflow in the current field/frame.
"
Enable this bit to mitigate the sporadic underflows.
[why]
For dual eDP when setting the new settings we need to set
command version to DMUB_CMD_PSR_CONTROL_VERSION_1, otherwise
DMUB will not read panel_inst parameter.
[how]
Instead of PSR_VERSION_1 pass DMUB_CMD_PSR_CONTROL_VERSION_1
Currently, each screen update triggers an I2C transfer of all screen
data, up to 1 KiB of data for a 128x64 display, which takes at least 20
ms in Fast mode.
Reduce the amount of transferred data by only updating the rectangle
that changed. Remove the calls to ssd1307fb_set_col_range() and
ssd1307fb_set_page_range() during initialization, as
ssd1307fb_update_rect() now takes care of that.
Note that for now the optimized operation is only used for fillrect,
copyarea, and imageblit, which are used by fbcon.
Simplify the nested loops to handle conversion from linear frame buffer
to ssd1307 page layout:
1. Move last page handling one level up, as the value of "m" is the
same inside a page,
2. array->data[] is filled linearly, so there is no need to
recalculate array_idx over and over again; a simple increment is
sufficient.
Daniel Vetter [Fri, 23 Jul 2021 08:34:57 +0000 (10:34 +0200)]
drm/plane: Move drm_plane_enable_fb_damage_clips into core
We're trying to have a fairly strict split between core functionality
that defines the uapi, including the docs, and the helper functions to
implement it.
Move drm_plane_enable_fb_damage_clips and associated kerneldoc into
drm_plane from drm_damage_helper.c to fix this.
Daniel Vetter [Fri, 23 Jul 2021 08:34:56 +0000 (10:34 +0200)]
drm/plane: check that fb_damage is set up when used
There's two stages of manual upload/invalidate displays:
- just handling dirtyfb and uploading the entire fb all the time
- looking at damage clips
In the latter case we support it through fbdev emulation (with
fb_defio), atomic property, and with the dirtfy clip rects.
Make sure at least the atomic property is set up as the main official
interface for this. Ideally we'd also check that
drm_atomic_helper_dirtyfb() is used and that fbdev defio is set up,
but that's quite a bit harder to do. Ideas very much welcome.
From a cursor audit drivers seem to be getting this right mostly, but
better to make sure. At least no one is bypassing the accessor
function.
v2:
- use drm_warn_once with a meaningful warning string (José)
- don't splat in the atomic check code for everyone (intel-gfx-ci)
It's not used. Drivers should instead use the helpers anyway.
Currently both vbox and i915 hand-roll this and it's not the greatest.
vbox looks buggy, and i915 does a bit much that helpers would take
care of I think.
Randy Dunlap [Tue, 27 Jul 2021 05:04:47 +0000 (22:04 -0700)]
efi: sysfb_efi: fix build when EFI is not set
When # CONFIG_EFI is not set, there are 2 definitions of
sysfb_apply_efi_quirks(). The stub from sysfb.h should be used
and the __init function from sysfb_efi.c should not be used.
../drivers/firmware/efi/sysfb_efi.c:337:13: error: redefinition of ‘sysfb_apply_efi_quirks’
__init void sysfb_apply_efi_quirks(struct platform_device *pd)
^~~~~~~~~~~~~~~~~~~~~~
In file included from ../drivers/firmware/efi/sysfb_efi.c:26:0:
../include/linux/sysfb.h:65:20: note: previous definition of ‘sysfb_apply_efi_quirks’ was here
static inline void sysfb_apply_efi_quirks(struct platform_device *pd)
^~~~~~~~~~~~~~~~~~~~~~
drivers/firmware: fix SYSFB depends to prevent build failures
The Generic System Framebuffers support is built when the COMPILE_TEST
option is enabled. But this wrongly assumes that all the architectures
declare a struct screen_info.
This is true for most architectures, but at least the following do not:
arc, m68k, microblaze, openrisc, parisc and s390.
By attempting to make this compile testeable on all architectures, it
leads to linking errors as reported by the kernel test robot for parisc:
All errors (new ones prefixed by >>):
hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init':
(.init.text+0x24): undefined reference to `screen_info'
>> hppa-linux-ld: (.init.text+0x28): undefined reference to `screen_info'
To prevent these errors only allow sysfb to be built on systems that are
going to need it, which are x86 BIOS and EFI.
The EFI Kconfig symbol is used instead of (ARM || ARM64 || RISC) because
some of these architectures only declare a struct screen_info if EFI is
enabled. And also, because the SYSFB code is only used for EFI on these
architectures. For !EFI the "simple-framebuffer" device is registered by
OF when parsing the Device Tree Blob (if a DT node for this was defined).
Nicolas Boichat [Tue, 27 Jul 2021 01:45:21 +0000 (09:45 +0800)]
drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features
Many of the DSI flags have names opposite to their actual effects,
e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
be disabled. Fix this by including _NO_ in the flag names, e.g.
MIPI_DSI_MODE_NO_EOT_PACKET.
Add vendor prefix for Shenzhen QiShenglong Industrialist Co., Ltd.
QiShenglong is a Chinese manufacturer of handheld gaming consoles, most of
which run (very old) versions of Linux.
QiShenglong is known as Hamy.
projects / linux.git / log