于 2026年5月15日 GMT+08:00 17:08:25，Joey Lu <[email protected]> 写道：
>
>On 5/15/2026 4:38 PM, Icenowy Zheng wrote:
>> 在 2026-05-15五的 14:25 +0800，Joey Lu写道：
>>> On 5/12/2026 9:12 PM, Icenowy Zheng wrote:
>>>> 在 2026-05-12二的 18:59 +0800，Joey Lu写道：
>>>>> On 5/12/2026 6:01 PM, Icenowy Zheng wrote:
>>>>>> 在 2026-05-12二的 17:06 +0800，Joey Lu写道：
>>>>>>
>>>>>> ======= 8< =============
>>>>>>>>>>> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>>> b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>>> index 7a93049368db..225af322de32 100644
>>>>>>>>>>> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>>> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>>> @@ -164,13 +164,16 @@ static void
>>>>>>>>>>> vs_bridge_enable_common(struct
>>>>>>>>>>> vs_crtc *crtc,
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_CLK_E
>>>>>>>>>>> N);
>>>>>>>>>>> regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG(output),
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_RUNNI
>>>>>>>>>>> NG);
>>>>>>>>>>> - regmap_clear_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>>> -
>>>>>>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>>>>>>> - regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>>> -
>>>>>>>>>>> VSDC_DISP_PANEL_START_RUNNIN
>>>>>>>>>>> G(ou
>>>>>>>>>>> tput));
>>>>>>>>>>> - regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>>>>>>>>>>> id),
>>>>>>>>>>> -
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX_CO
>>>>>>>>>>> MMIT);
>>>>>>>>>>> + if (dc->info->has_config_ex) {
>>>>>>>>>>> + regmap_clear_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>>> +
>>>>>>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>>>>>>> + regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>>> + VSDC_DISP_PANEL_STAR
>>>>>>>>>>> T_RU
>>>>>>>>>>> NNIN
>>>>>>>>>>> G(ou
>>>>>>>>>>> tput
>>>>>>>>>>> ));
>>>>>>>>>>> +
>>>>>>>>>>> + regmap_set_bits(dc->regs,
>>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
>>>>>>>>>>> + VSDC_DISP_PANEL_CONF
>>>>>>>>>>> IG_E
>>>>>>>>>>> X_CO
>>>>>>>>>>> MMIT
>>>>>>>>>>> );
>>>>>>>>>> Should the commit operation happen on
>>>>>>>>>> DC8000/DCUltraLite
>>>>>>>>>> too?
>>>>>>>>>> (By
>>>>>>>>>> writing to DcregFrameBufferConfig0.VALID).
>>>>>>>>>>
>>>>>>>>>> Many registers written has "Note: This field is double
>>>>>>>>>> buffered" in
>>>>>>>>>> the
>>>>>>>>>> DCUltraLite documentation.
>>>>>>>>>>
>>>>>>>>>> I suggest create a static function for commit -- write
>>>>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>> corresponding commit bit on DC8200, and write to
>>>>>>>>>> DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
>>>>>>>>> [a] There is no commit operation for DCUltra Lite.
>>>>>>>>> I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID
>>>>>>>>> (BIT(3))
>>>>>>>>> is a
>>>>>>>>> hardware-managed double-buffer status bit: hardware
>>>>>>>>> writes
>>>>>>>>> 1=PENDING
>>>>>>>>> when a new register set is ready and clears to 0=WORKING
>>>>>>>>> after
>>>>>>>>> the
>>>>>>>>> VBLANK copy. Software must never write it, and there is
>>>>>>>>> no
>>>>>>>>> polling
>>>>>>>>> use
>>>>>>>> It seems to be writable and controls whether register
>>>>>>>> buffering
>>>>>>>> is
>>>>>>>> enabled, see [1].
>>>>>>>>
>>>>>>>> The description of this bit in MA35D1 TRM says "This
>>>>>>>> ensures a
>>>>>>>> frame
>>>>>>>> will always start with a valid working set if this register
>>>>>>>> is
>>>>>>>> programmed last, which reduces the need for SW to wait for
>>>>>>>> the
>>>>>>>> start of
>>>>>>>> a VBLANK signal in order to ensure all states are loaded
>>>>>>>> before
>>>>>>>> the
>>>>>>>> next VBLANK", which indicates some kind of "committing
>>>>>>>> write",
>>>>>>>> although
>>>>>>>> the code at [1] seems to indicate that double buffering is
>>>>>>>> only
>>>>>>>> enabled
>>>>>>>> when bit is cleared.
>>>>>>>>
>>>>>>>> Anyway this bit should be programmable, and "Software must
>>>>>>>> never
>>>>>>>> write
>>>>>>>> it" contradicts with the MA35D1 TRM.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Icenowy
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/drivers/gpu/drm/eswin/es_dc_hw.c#L993
>>>>>>> Thank you for the correction. I'll add
>>>>>>> `#define VSDC_FB_CONFIG_VALID BIT(3)` to
>>>>>>> vs_primary_plane_regs.h
>>>>>>> and
>>>>>>> write it in `vs_primary_plane_commit()` for non-config_ex
>>>>>>> variants.
>>>>>>>>> case in the driver that requires a named constant. For
>>>>>>>>> non-
>>>>>>>>> config_ex
>>>>>>>>> variants, `vs_primary_plane_commit()` performs no commit
>>>>>>>>> operation —
>>>>>>>>> `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in
>>>>>>>>> `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET`
>>>>>>>>> (BIT(4))
>>>>>>>>> is
>>>>>>>>> set/cleared in the bridge enable/disable paths.
>>>>>> Well according to the driver code for DC8000 from Eswin, and
>>>>>> the
>>>>>> bit
>>>>>> named "VALID", maybe it should be cleared before programming
>>>>>> the
>>>>>> registers, and set after programming registers, to make the
>>>>>> process
>>>>>> of
>>>>>> programming registers atomic from the perspective of the
>>>>>> display
>>>>>> controller.
>>>>>>
>>>>>> Anyway this should require testing on real hardware to verify.
>>>>>>
>>>>>> By the way, I see multiple peripheral drivers for MA35D1 get
>>>>>> applied in
>>>>>> the torvalds tree, but the device tree is still only a
>>>>>> skeleton;
>>>>>> when
>>>>>> will the device tree be updated?
>>>>>>
>>>>>> Thanks,
>>>>>> Icenowy
>>>>> Thanks for pointing this out. I’ll perform tests on real hardware
>>>>> since
>>>>> I haven’t used this bit before.
>>>>>
>>>>> As for the device tree, we plan to update it comprehensively
>>>>> after
>>>>> completing several major IPs, with the goal of releasing the
>>>>> update
>>>>> later this year.
>>>> Well I bought a MA35D1 board (MYIR MYB-LMA35 + RGB LCD) earlier
>>>> this
>>>> year (and this is where I got the MA35D1 identification register
>>>> values). Hope I can have a chance to test this driver by myself.
>>>>
>>>> As MMC, Ethernet and USB support is all applied, maybe it's already
>>>> worthy to update the device tree ;-)
>>>>
>>>> Thanks,
>>>> Icenowy
>>> Yes you can!
>>>
>>> I have performed hardware validation on the MA35D1 and found that
>>> this
>>> bit acts as a manual latch for the shadow registers rather than an
>>> auto-clearing trigger, which clarifies the slightly ambiguous
>>> description in the TRM.
>>>
>>> Following your suggestion, I will align the implementation with
>>> ESWIN's
>>> DC8000 logic: setting the VALID bit at atomic_begin and clearing it
>> Ah do you mean clearing it at begin and setting it at flush?
>>
>> In the Eswin driver (which seems to be based on reference code by
>> Verisilicon, I saw similar driver code for DC8200),
>> dc_hw_enable_shadow_register() clears VALID bit when enable is true,
>> and all register setting sequences calls that function with enable =
>> true before setting and enable = false after setting.
>>
>> In addition, considering this bit is called "VALID" instead of
>> "INVALID", I think it represents that the DC will apply the new setting
>> when it's set and keep the current setting when it's cleared, so I
>> think it should be cleared before modeset sequence and be set after
>> modeset sequence.
>>
>> Thanks,
>> Icenowy
>Thanks for pointing that out. To clarify, the TRM defines the states for this
>bit as:
>1: PENDING (Shadow registers are locked; incoming CPU writes are held in the
>shadow buffer).
>0: WORKING (Shadow registers are unfrozen/live; configuration is committed).
This sounds reasonable, thanks for the clarification.
Sorry for me to be too lazy to verify it in HW.
Thanks,
Icenowy
>
>Regarding the Eswin reference, `dc_hw_enable_shadow_register(hw, false)`
>actually writes a 1 to isolate the registers during a batch update, and then
>transitions back to true (0) to flush them out.
>My hardware test confirms this sequence:
>
>- atomic_begin: We set VALID = 1. This safely freezes the current scanout
>configuration so we can update multiple registers (like frame addresses and
>pitches) without mid-frame tearing.
>- atomic_update: We write the new register values safely into the frozen
>shadow space.
>- atomic_flush: We clear VALID = 0. This releases the shadow lock, triggering
>the hardware to latch the whole batch atomically.
>
>If we reverse this logic—leaving the bit at 1 after the flush — the hardware
>remains permanently stuck in the PENDING state, waiting to be unfrozen, which
>starves the display engine and results in the blank screen behavior I observed.
>>> at
>>> atomic_flush. My tests confirm this allows the hardware to latch the
>>> plane configuration correctly while avoiding the blank screen issues
>>> observed with other configurations.
>>>
>>> I am preparing the v2 patchset with this change, along with the
>>> requested commit splits, and will submit it shortly.🙂
>>>
>>>>>>>> ========= 8< ==========
>>>>>>>>
