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

[AngeloGioacchino Del Regno]

Il 26/02/26 11:26, AngeloGioacchino Del Regno ha scritto:
> 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

Eh, sorry for the double email, I was meaning MT6789 Helio G99 - just to be
extremely clear, though that wasn't much important (given that the WDMA IP is
anyway practically the same between the two..).

> 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
>>
>>>
>>
> 
>