On 2/28/22 07:37, Liu Ying wrote:
Hi Marek,
Hi,
On Mon, 2022-02-28 at 01:45 +0100, Marek Vasut wrote:
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3
and is completely different from the LCDIFv3 found in i.MX23 in that it
In i.MX23 reference manual, there is no LCDIFv3 found, but only LCDIF.
See i.MX23 HW_LCDIF_VERSION MAJOR=0x3 , that's LCDIF V3 . MX28 has LCDIF
V4 .
has a completely scrambled register layout compared to all previous LCDIF
It looks like no single register of i.MX8MP LCDIFv3 overlaps with
registers in other i.MX2x/6x/7x/8x LCDIFs. The LCDIFv3 block diagram is
totally different from the LCDIF block diagram, according to the SoC
reference manuals. LCDIFv3 supports SHADOW_EN bit to update horizontal
and vertical size of graphic, position of graphic on the panel, address
of graphic in memory and color formats or color palettes, which is not
supported by LCDIF and impacts display driver control mechanism
considerably. LCDIF supports DOTCLK interface, MPU interface and VSYNC
interface, while LCDIFv3 only supports parallel output as a counterpart
of the DOTCLK interface.
Generally speaking, LCDIFv3 is just a new display IP which happens to
have the word 'LCDIF' in its name. Although both of LCDIFv3 and LCDIF
are display controllers for scanning out frames onto display devices, I
don't think they are in one family.
So, LCDIFv3 deserves a new separate dt-binding, IMO.
It seems to me a lot of those bits just map to their previous
equivalents in older LCDIF, others were dropped, so this is some sort of
new LCDIF mutation, is it not ?
I am aware NXP has a separate driver in its downstream, but I'm not
convinced the duplication of boilerplate code by introducing a separate
driver for what looks like another LCDIF variant is the right approach.
variants. The new LCDIFv3 also supports 36bit address space. However,
except for the complete bit reshuffling, this is still LCDIF and it still
works like one.
[...]
