On 02/02/2023 21:41, Justin Green wrote:
Yes, I had a comment on the naming in that patch. Never the less, I think if we
don't need to "overwrite" the value, we should use just one struct for the
values instead of copying them to the different .c files and give them SoC
specific names.
I don'
> Yes, I had a comment on the naming in that patch. Never the less, I think if
> we
> don't need to "overwrite" the value, we should use just one struct for the
> values instead of copying them to the different .c files and give them SoC
> specific names.
I don't have a very strong opinion about t
On 02/02/2023 19:59, Justin Green wrote:
Hi Matthias,
mt8173_formats are the same as the old struct formats. Maybe we should use that
and only overwrite where we actually use a different array.
I think this was sort of how the original patch worked, but we wanted
to add some flexibility to
Hi Matthias,
> mt8173_formats are the same as the old struct formats. Maybe we should use
> that
> and only overwrite where we actually use a different array.
I think this was sort of how the original patch worked, but we wanted
to add some flexibility to allow different components to support
dif
On 01/02/2023 18:02, Justin Green wrote:
Add an DDP component interface for querying pixel format support and move list
of supported pixel formats into DDP components instead of mtk_drm_plane.c
Tested by running Chrome on an MT8195.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek
Add an DDP component interface for querying pixel format support and move list
of supported pixel formats into DDP components instead of mtk_drm_plane.c
Tested by running Chrome on an MT8195.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 ++
drivers/gpu/drm/me
