[PATCH 00/11] Plane Color Pipeline support for MediaTek

[AngeloGioacchino Del Regno]

Il 26/02/26 07:24, CK Hu (胡俊光) ha scritto:
> On Fri, 2026-02-06 at 08:28 -0500, Nícolas F. R. A. Prado wrote:
>> On Fri, 2026-02-06 at 11:09 +0200, Pekka Paalanen wrote:
>>> On Fri, 2 Jan 2026 13:40:21 -0500
>>> Harry Wentland <harry.wentland at amd.com> wrote:
>>>
>>>> On 2026-01-01 07:37, Shengyu Qu wrote:
>>>>>
>>>>>
>>>>> 在 2025/12/30 02:53, Shengyu Qu 写道:
>>>>>>
>>>>>>
>>>>>> 在 2025/12/24 3:44, NÃ colas F. R. A. Prado 写道:
>>>
>>>>>>> Given the lack of support for writeback connectors on the
>>>>>>> MediaTek KMS driver, combined with limited hardware
>>>>>>> documentation, I haven't been able to verify the correctness
>>>>>>> of
>>>>>>> each curve, only that they were visually sane (gamma curves
>>>>>>> made
>>>>>>> the image on the display brighter, while inverse gamma made
>>>>>>> it
>>>>>>> darker).
>>>>>>
>>>>>> Hmmm I don't think this is acceptable. sRGB/scRGB has two
>>>>>> transfer
>>>>>> functions mentioned in original specification[1]. To keep color
>>>>>> accuracy, we need someone from mediatek confirm whether this is
>>>>>> piece- wise or pure power 2.2 transfer function, this is
>>>>>> already
>>>>>> done in original amdgpu color pipeline series, sRGB means
>>>>>> piece-wise while also dedicated power 2.2 function exists.
>>>>
>>>> Not sure what you mean with this not being acceptable. This is
>>>> about
>>>> enabling HW support for this functionality. Not every HW has
>>>> writeback for testing. At some point you'll have to trust the
>>>> driver
>>>> devs if you're going to use functionality of the driver. We're not
>>>> always going to get everything perfect, but if that's really such a
>>>> worry you can always use shaders to do precisely what you want.
>>>>
>>>
>>> Hi Harry,
>>>
>>> yes, but I understood that in this case, the hardware documentation
>>> available is so vague that it's impossible to say what it will
>>> actually
>>> do. There are no formulas given or referenced in the documentation,
>>> are
>>> there, Nícolas?
>>
>> No formulas at all, the only documentation I had available for the
>> curves was the register definition, which simply lists the possible
>> values: SCRGB, BT709, BT2020, HLG.
> 
> Hi, Nicolas:
> 
> In [1], it shows OVL could output data to WDMA which could write data into DRAM.
> Its control is similar to RDMA. RDMA read data from DRAM and WDMA write data into DRAM.
> Do you have interest to implement WDMA?

I wrote a WDMA driver a long ago, but I couldn't get it to work (though, I admit I
didn't try hard to actually get it working).... if you want to take a look to check
if anything obvious is missing, the driver is here:

https://gitlab.collabora.com/mediatek/aiot/linux/-/blob/mediatek-dev/drivers/gpu/drm/mediatek/mtk_disp_wdma.c?ref_type=heads

The driver I wrote was supposed to work on MT8781 Helio G99 (for a personal project
as in upstreaming of the Xiaomi Poco M5 smartphone) and on MT8195 as a PoC.
I did test both platforms and this driver didn't work on both... not sure if that
was because I misconfigured the MMSYS routing (on both) or if there's any actual
issue with the driver I wrote.

Again, didn't invest much time on this, anyway, so some obvious issue might be
present.

Cheers,
Angelo

> This is just a suggestion.
> I could accept we believe what document say first and wait for someone to verify it.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/mediatek/mt8195-mmsys.h?h=v7.0-rc1#n8
> 
> Regards,
> CK
> 
>>
>