linux-kernel - Re: [PATCH v1 4/5] drm/mediatek: mtk_dpi: Allow additional output formats on MT8195/88

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <17b19733-b203-40bd-ba14-07eb66f02d6c@collabora.com>
Date: Tue, 22 Apr 2025 15:42:07 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: CK Hu (胡俊光) <ck.hu@...iatek.com>,
 "chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>
Cc: Lewis Liao (廖柏鈞) <Lewis.Liao@...iatek.com>,
 Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>,
 Ives Chenjh (陳俊弘) <Ives.Chenjh@...iatek.com>,
 "simona@...ll.ch" <simona@...ll.ch>,
 TommyYL Chen (陳彥良) <TommyYL.Chen@...iatek.com>,
 "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
 "airlied@...il.com" <airlied@...il.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
 "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
 "linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
 "kernel@...labora.com" <kernel@...labora.com>
Subject: Re: [PATCH v1 4/5] drm/mediatek: mtk_dpi: Allow additional output
 formats on MT8195/88

Il 22/04/25 08:01, CK Hu (胡俊光) ha scritto:
> Hi, Angelo:
> 
> On Wed, 2025-04-09 at 15:13 +0200, AngeloGioacchino Del Regno wrote:
>> External email : Please do not click links or open attachments until you have verified the sender or the content.
>>
>>
>> Allow additional output formats in both DPI and DP_INTF blocks of
>> the MT8195 and MT8188 SoCs (as the latter is fully compatible with,
>> hence reuses, the former's platform data for both blocks) by adding:
>>
>> 1. New formats to the `mt8195_output_fmts` array for dp_intf,
>>     lacking YUV422 12-bits support, and adding RGB888 2X12_LE/BE
>>     (8-bits), BGR888 (8-bits) RGB101010 1x30 (10-bits), and YUV
>>     formats, including YUV422 8/10 bits, and YUV444 8/10 bits; and
>> 2. A new `mt8195_dpi_output_fmts` array for DPI only, with all of
>>     for formats added to dp_intf and with the addition of the
>>     YUYV12_1X24 (YUV422 12-bits) output format.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>> ---
>>   drivers/gpu/drm/mediatek/mtk_dpi.c | 24 ++++++++++++++++++++++--
>>   1 file changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> index a9e8113a1618..9de537a77493 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
>> @@ -1093,9 +1093,29 @@ static const u32 mt8183_output_fmts[] = {
>>          MEDIA_BUS_FMT_RGB888_2X12_BE,
>>   };
>>
>> +static const u32 mt8195_dpi_output_fmts[] = {
>> +       MEDIA_BUS_FMT_RGB888_1X24,
>> +       MEDIA_BUS_FMT_RGB888_2X12_LE,
>> +       MEDIA_BUS_FMT_RGB888_2X12_BE,
>> +       MEDIA_BUS_FMT_RGB101010_1X30,
>> +       MEDIA_BUS_FMT_YUYV8_1X16,
>> +       MEDIA_BUS_FMT_YUYV10_1X20,
>> +       MEDIA_BUS_FMT_YUYV12_1X24,
>> +       MEDIA_BUS_FMT_BGR888_1X24,
> 
> What's the order you follow?
> I would like RGB together and YUV together.
> 

Actually, BGR888_1X24 should come before RGB888_1X24 now that you make me notice..!

Those are ordered by preference (and the order won't be respected in the actual
code anyway).... as in:
- For RGB 8-bits, RGB888_1X24 is the one that should be preferred
- For RGB 10 bits there's only one so ...
- For yuv modes - YUYV is preferred to YUV
   - there's only one for each, so in that case it's alphabetical
     meaning that yuyv8 comes before yuyv10

If you want, you can reorder them as you wish anyway - there's no strong reason
against any kind of ordering.

Besides, if you can change to the order that you prefer while applying this commit
that's great - otherwise just tell me what order you precisely want and I'll send
a v2 for the entire series :-)

Cheers,
Angelo

> Regards,
> CK
> 
>> +       MEDIA_BUS_FMT_YUV8_1X24,
>> +       MEDIA_BUS_FMT_YUV10_1X30,
>> +};
>> +
>>   static const u32 mt8195_output_fmts[] = {
>>          MEDIA_BUS_FMT_RGB888_1X24,
>> +       MEDIA_BUS_FMT_RGB888_2X12_LE,
>> +       MEDIA_BUS_FMT_RGB888_2X12_BE,
>> +       MEDIA_BUS_FMT_RGB101010_1X30,
>>          MEDIA_BUS_FMT_YUYV8_1X16,
>> +       MEDIA_BUS_FMT_YUYV10_1X20,
>> +       MEDIA_BUS_FMT_BGR888_1X24,
>> +       MEDIA_BUS_FMT_YUV8_1X24,
>> +       MEDIA_BUS_FMT_YUV10_1X30,
>>   };
>>
>>   static const struct mtk_dpi_factor dpi_factor_mt2701[] = {
>> @@ -1208,8 +1228,8 @@ static const struct mtk_dpi_conf mt8192_conf = {
>>
>>   static const struct mtk_dpi_conf mt8195_conf = {
>>          .max_clock_khz = 594000,
>> -       .output_fmts = mt8183_output_fmts,
>> -       .num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
>> +       .output_fmts = mt8195_dpi_output_fmts,
>> +       .num_output_fmts = ARRAY_SIZE(mt8195_dpi_output_fmts),
>>          .pixels_per_iter = 1,
>>          .is_ck_de_pol = true,
>>          .swap_input_support = true,
>> --
>> 2.49.0
>>
>