[PATCH 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant

Marek Vasut marex at denx.de
Fri Apr 1 11:46:47 UTC 2022


On 4/1/22 10:22, Stefan Agner wrote:
> On 2022-03-22 15:28, Marek Vasut wrote:
>> Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
>> completely different from the LCDIFv3 found in i.MX23 in that it has
>> a completely scrambled register layout compared to all previous LCDIF
>> variants. The new LCDIFv3 also supports 36bit address space.
>>
>> Add a separate driver which is really a fork of MXSFB driver with the
>> i.MX8MP LCDIF variant handling filled in.
>>
>> Signed-off-by: Marek Vasut <marex at denx.de>
>> Cc: Alexander Stein <alexander.stein at ew.tq-group.com>
>> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>> Cc: Lucas Stach <l.stach at pengutronix.de>
>> Cc: Peng Fan <peng.fan at nxp.com>
>> Cc: Robby Cai <robby.cai at nxp.com>
>> Cc: Sam Ravnborg <sam at ravnborg.org>
>> Cc: Stefan Agner <stefan at agner.ch>
>> ---
>>   drivers/gpu/drm/mxsfb/Kconfig      |  16 +
>>   drivers/gpu/drm/mxsfb/Makefile     |   2 +
>>   drivers/gpu/drm/mxsfb/lcdif_drv.c  | 367 +++++++++++++++++++++
>>   drivers/gpu/drm/mxsfb/lcdif_drv.h  |  48 +++
>>   drivers/gpu/drm/mxsfb/lcdif_kms.c  | 492 +++++++++++++++++++++++++++++
>>   drivers/gpu/drm/mxsfb/lcdif_regs.h | 243 ++++++++++++++
> 
> As this is completely ortogonal to mxsfb driver, shouldn't this live in
> its own directory (drivers/gpu/drm/lcdif/)?

No, if you look closely, the MXSFB (i.e. LCDIF) and this LCDIFv3 (i.e. 
MX8MP/MXRT LCDIF) are very similar hardware-wise and they even share a 
lot of code (about 60%). They should be in the same directory to make it 
easier to share common code between the mxsfb and lcdif driver. Look at 
the discussion:
[PATCH 9/9] drm: mxsfb: Add support for i.MX8MP LCDIF variant
Originally the MX8MP LCDIF was a trivial addition to the MXSFB driver, 
but there was a demand to spin it off into separate driver entirely, 
with its own copy of everything. So, here it is. I believe there is 
potential for deduplication though.


More information about the dri-devel mailing list