linux-kernel - Re: [PATCH 00/11] drm/meson: Add G12A Support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <83b873f0-f816-9997-4e62-82d4dfce4f04@baylibre.com>
Date:   Tue, 9 Apr 2019 10:51:51 +0200
From:   Neil Armstrong <narmstrong@...libre.com>
To:     Jerome Brunet <jbrunet@...libre.com>,
        dri-devel@...ts.freedesktop.org
Cc:     linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] drm/meson: Add G12A Support

Hi,

On 09/04/2019 10:42, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> The Amlogic G12A SoC offers very close Video Display
>> functionnalities with it's older GXBB, GXL & GXM predecessors.
>>
>> The main differences are :
>> - G12A Support now 3 "real" OSD planes with a new Blender module
>> - Instead of having a single Scaler for OSD1, G12A has two scaler
>>   that can be applied to 2 out of the 3 OSD planes or on the outputs
>>   of the blender module.
>> - The HDMI PHY now support RX-SENSE, Dynamic HDR and it's registers are
>>   now memory mapped instead of using an internal bus.
>> - The VPU now support a DSI interface to connect a display, using
>>   the Synopsys DSI controller and a custom PHY
>>
>> The complex Blender routing, HDMI RX-SENSE, Dynamic HDR and DSI support
>> are not handled in this patchset.
>>
>> This patchset implements on-par support with the currently support
>> GXBB, GXL and GXM SoCs. There is no support delta with this patchset.
>>
>> patch 10 & 11 implements the bindings found at [1].
>>
>> [1] https://lkml.kernel.org/r/20190313141030.5958-1-narmstrong@baylibre.com
>>
>> Neil Armstrong (11):
>>   drm/meson: Switch PLL to 5.94GHz base for 297Mhz pixel clock
>>   drm/meson: Add registers for G12A SoC
>>   drm/meson: Add G12A Support for VPP setup
>>   drm/meson: Add G12A Support for VIU setup
>>   drm/meson: Add G12A support for OSD1 Plane
>>   drm/meson: Add G12A Support for the Overlay video plane
>>   drm/meson: Add G12A support for plane handling in CRTC driver
>>   drm/meson: Add G12A support for CVBS Encoer
>>   drm/meson: Add G12A Video Clock setup
>>   drm/meson: Add G12A compatible
>>   drm/meson: Add G12A support for the DW-HDMI Glue
>>
>>  drivers/gpu/drm/meson/meson_crtc.c      | 269 +++++++++++++++++++-----
>>  drivers/gpu/drm/meson/meson_drv.c       |   1 +
>>  drivers/gpu/drm/meson/meson_drv.h       |   4 +
>>  drivers/gpu/drm/meson/meson_dw_hdmi.c   | 163 +++++++++++---
>>  drivers/gpu/drm/meson/meson_dw_hdmi.h   |  32 ++-
>>  drivers/gpu/drm/meson/meson_overlay.c   |  10 +-
>>  drivers/gpu/drm/meson/meson_plane.c     |  15 +-
>>  drivers/gpu/drm/meson/meson_registers.h | 247 ++++++++++++++++++++++
>>  drivers/gpu/drm/meson/meson_vclk.c      | 123 +++++++++--
>>  drivers/gpu/drm/meson/meson_venc.c      |  11 +-
>>  drivers/gpu/drm/meson/meson_venc_cvbs.c |  25 ++-
>>  drivers/gpu/drm/meson/meson_viu.c       |  72 ++++++-
>>  drivers/gpu/drm/meson/meson_vpp.c       |  51 +++--
>>  13 files changed, 880 insertions(+), 143 deletions(-)
>>
> 
> on the u200 and sei510
> Tested-by: Jerome Brunet <jbrunet@...libre.com>
> 
> I can't pretend to have a deep understanding of this subsystem, but as far as
> I can tell, there is nothing crazy in there. With the comments around the use
> of constants and defines fixed, you can add
> 
> Reviewed-by: Jerome Brunet <jbrunet@...libre.com>
> 
> As a possible future enhancement, it would be nice if you could trim the use
> of *_is_compatible() functions. I think it would make the code easier to
> follow and review.
> 

Thanks for the overall review,

I will do a complete fixup of the constants and defines in a follow-up patchset,
since the already-merged code also needs a good cleanup.

I'll do a more complete refactoring to get rid of the _is_compatible() stuff
in a second time, it needs much more work to handle correctly the 4 SoC families.

Neil