Repository navigation
Haltia (B8000-H) kernel patches: what we have, what we'd like to send #84
Description
Hi! This is the plan behind haltia-de/device-lenovo-b8000h#49. We run Linux 7.1 on the Lenovo B8000-H (3G model, MT8389) for real users (Pertin Haltia images). Our base is blade/v7.1 @ 7dd245445adf. On top of it are 54 patch files (0001–0049) in linux-port/patches/. Much of this code was written with AI assistance (Claude); every change was then run on the tablet. Below: what each group does, what I found in your blade/v7.1 and dev/v7.1/mt6589-drm-ox-alpha, and what we'd like to send.
A question first: CNTPCT on MT6589
On our boards, CNTPCT's high word only follows GPT6 when something reads GPT6's registers. Unread, CNTPCT goes back by 2^32 ticks (330 s at 13 MHz) at every wrap of the low word. With the arch timer as clocksource, our tablet hung or rebooted at 330–386 s uptime. Measurements: docs/power.md (Russian).
In blade/v7.1 the arch timer (rating 400) wins over the GPT clocksource (GPT2, rating 300). As far as I can see, GPT6 is only switched on in mach-mediatek/mediatek.c and never read. Have you seen time jumps or hangs around 330 s, or is something on your boards reading GPT6 that I missed? The fix we use is the PR below.
Ready now
| Series | Our patches | In your tree |
|---|---|---|
patch/mt6589-arch-timer-gpt-latch: the arch timer gives per-CPU ticks only, and time and sched_clock stay on the GPT. GPT6 is read before each event, and events are kept 5 ms off the wrap. Plus NO_HZ_IDLE and HIGH_RES_TIMERS |
0041, 0042 | Not present. PR: #83. Two commits on 1f08cc2dad56. In daily use since 15 Oct 2026 |
What we'd like to send later, as time allows
No promises on dates: our time currently goes to a Wi-Fi memory corruption (below).
| Topic | Our patches | In your tree |
|---|---|---|
| pinctrl: keep eMMC DAT1 on MSDC0 when the MT6320 asks for EINT43 (mode 2 takes DAT1 away: every write fails with a data CRC error) | 0013 | Not present: MSDC0_DAT1 still has MTK_EINT_FUNCTION(2, 43) |
pmdomain: four MFG SRAM banks (GENMASK(11, 8)), not one |
0021 | Not present: BIT(8) |
| rmi4: split long I2C reads for adapters with a short maximum transfer | 0006 | Not present |
pstore: ramoops in 1 MiB of DRAM below LK's framebuffer (0xbf500000), 32 KiB records. The 7 KiB SRAM region cut every oops (-28) |
0049 | Not present |
| B8000-H board DTS: touch on VGP5, MT6628 on UART2/MSDC3, fuel gauge on I2C6 and no BQ27541, vibrator on the VIBR LDO, eMMC/SD layouts | 0001, 0004, 0007, 0009–0011, 0016, 0024, 0028, 0030, 0039 | You have b8000-f and b6000. We'd add mt6589-lenovo-b8000-h.dts over your mt6589-lenovo-b8000.dtsi |
MSDCPLL 208 MHz as msdcpll/2 (VCO/8 ahead of the /4 post divider, not after it), MSDC3 for SDIO |
0025 | You define it differently; I haven't checked whether the divider matches |
| drm/mediatek MT6589: cached dumb buffers, flushed on dirty (pixman blending into write-combined buffers pinned a Cortex-A7 core at 100%); CRTC kept on across DPMS, with the vblank event still sent | 0027, 0029, 0036 | Not present. Your display path differs, so these may be findings rather than patches |
| drm/mediatek MT6589: OVL/RDMA FIFO threshold and GMC; mask the OVL frame IRQ that LK leaves on | 0020, 0040 | You have related OVL GMC work in dev; let's compare. Our reasoning: docs/scroll-tear.md |
| Front camera: OV9760 rotation in DT, no 640x480 mode (wrong Bayer order), stop IMGO at once on a pass-1 error, SENINF MCLK | 0046, haltia-de/device-lenovo-b8000h#41, haltia-de/device-lenovo-b8000h#42, haltia-de/device-lenovo-b8000h#43 | You have your own OV9760 and camera dtsi. We'd send fixes against yours |
Already fixed in your tree; we'll drop ours when we move our base
- 0005: pinctrl GPIO_MODE layout (
blade/v7.1) - 0014: mmc queue, clear the single-block flag (
dev) - 0034: PMIC keys sampled after debounce (
dev) - 0048: ISP SRAM_PDN_ACK bits (
dev) - watchdog
EXRST_ENon restart: indev, but1f08cc2dad56("Revert watchdog changes") took it out ofblade/v7.1. On our boards LK leaves the bit off, and after arebootthe preloader then keeps the tablet powered off. We set it from userspace for now.
Not for your tree
DEBUGinstrumentation: 0003, 0015, 0051, 0052.- 0031 (an ALSA module ABI hack).
- 0033: builds MediaTek's MT6628 vendor driver and our old non-ASoC sound driver into the kernel. We'd rather move to your ASoC driver than send ours.
- 0038, 0045, 0047: product config (zram, netfilter, DMA-BUF heaps). The heaps may interest you for libcamera.
- PowerVR DDK 1.12 and ion-legacy (out of tree).
Findings we can share
-
MT6628 Wi-Fi memory corruption. We're chasing stack-protector panics in
__mmc_claim_hostthat happen while the Wi-Fi holds MSDC3 (Kernel panic: stack-protector in mmc_release_host from sdio_irq_work (k27c, after a video call) haltia-de/device-lenovo-b8000h#39). In the vendor driver we found two bugs (Keep MT6628 RX copies and SDIO reads inside their buffers (needs tablet verification) haltia-de/device-lenovo-b8000h#51):- an RX aggregate copy into a 2352-byte skb, with only the aggregate's total length checked;
- SDIO block rounding that reads past the caller's buffer.
Worth checking in your
wifi: mt6628work if it shares that code. -
Microphone capture registers of the MT6589 AFE, for your ASoC driver.
Questions
- Where to send PRs. I opened the timer PR against
blade/v7.1. Would you rather have series go tomainlinefrompatch/*, like yours? Easy to retarget. - Mainline. Would you take our commits into your LKML series? Our
Signed-off-bystays on them, and we'd answer review questions. You already know the MediaTek maintainers, and we can't take on the LKML process ourselves right now. - AI-assisted commits. You mark them with "(AI)" in the author name. We follow the kernel's rule: a human
Signed-off-byplusAssisted-by: Claude:claude-opus-5-5. Fine with you? - Who does what. You're working on MT6628, display, camera and ASoC right now, and so are we. Where would we help most, and where should we stay out of your way?
Activity
akku1139 commentedon Oct 28, 2026
Patch simple reviews
CNTPCT on MT6589
I'll test your fix and apply to main branch.
However, since it changes common ARM code, there may be issues with the upstream.
pinctrl: keep eMMC DAT1 on MSDC0 when the MT6320 asks for EINT43
EINT43 was wrong, should be fixed now: 55c7ee9
PMIC EINT is now working too.
pmdomain: four MFG SRAM banks (GENMASK(11, 8)), not one
Wow, It's my mistake. Datasheet (I'll send you later) says
GENMASK(11, 8)too.rmi4: split long I2C reads for adapters with a short maximum transfer
Ported: 34a9731
Touchpanel is now working.
pstore: ramoops in 1 MiB of DRAM below LK's framebuffer (0xbf500000), 32 KiB records
Interesting.
B8000-H board DTS
Nice.
(b6000 was added by stupid AI agent..., I only have b8000-f)
MSDCPLL 208 MHz
It may be the root cause of 200MHz MSDC unstability. I'll check and test it.
drm/mediatek MT6589: cached dumb buffers, flushed on dirty
SoC overheating due to the display was a problem.
I'll check it.
drm/mediatek MT6589: OVL/RDMA FIFO threshold and GMC; mask the OVL frame IRQ that LK leaves on
DRM dev branch uses dispsys resets. The lk state will probably not remain.
camera
I haven't even had a chance to try out the camera on the b8000 yet...
Wi-Fi memory corruption
In most cases, this occurs after pmos_continue_boot, it occurred during init for some reason,
I managed to get dump with
slub_debug=FZPU.It may help you too.
MT6589 AFE
The current dev branch has a bug that causes stereo headphones to play in mono...
PR
Please chose
blade/v7.1as destination and usedev/[version]/branch prefix for TeamYogaBlade2 internal PRs.blade branch is (basically) tested and stable.
Don't need
[PATCH]prefix. (andpatch/branch prefix) This is for managing LKML patches.Mainline
MT6589 LKML status is not good.
I'll send your patches with mine in future.
AI Attribution
(AI)in author name is not necessary as it's for my own commit management.Signed-off-by: It would be good to have.Assisted-by: This will become unnecessary upstream.I think it would be nice to be able to track which AI model made the changes, but it's not essential.
My works
MT6589 DRM: works, but backlight scaling is broken on dev branch now. It must have been working correctly at some point...
MT6628 mainline style drivers: Wi-Fi is tested (but buggy and unstable). They cannot be upstreamed due to their firmware.
Camera: Untested. Ported this to burn tokens using free LLM (Space Bunny Alpha aka MiniMax M3.1 Flash).
ASoC: Thanks to the additional work you've done, the built-in speaker now seems to be working properly.
JPEG, Vcodec: Untested.
GPU: Just for fun.
akku1139 commentedon Oct 28, 2026
closed by mistake...
akku1139 commentedon Oct 28, 2026
https://github.com/TeamYogaBlade2/documents
trudenboy commentedon Oct 28, 2026
Thank you very much for the careful review and for the datasheets. I will keep them private.
As you suggested, here are the patches as PRs :
dev/v7.1/mt6589-drm-ox-alpha, for discussion#86, #87 and #89 have been in daily use on our tree with hardware; on current
blade/v7.1they are build-tested, and I will boot them next week. #90 has only run on our display path, so it needs a test on your side.EINT43 and rmi4: I will drop ours and use yours. Thank you for the AFE warning too.
Your
slub_debugdump helps me a lot. My panics arestack-protectorhits inmmc_release_host, with a different Wi-Fi driver. In your dump only one bit changed (0xbb to 0xab), which looks like a stray write rather than an overflow. Our driver still has the two out-of-bounds bugs I mentioned, so I am fixing those first. Then I will runslub_debugand see whether something both trees share is left:mtk-sdon MSDC3, the chip and firmware, or code both drivers took from the vendor driver. I will share what I find.誠にありがとうございました。