public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Sui Jingfeng <15330273260@189.cn>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Thomas Zimmermann <tzimmermann@suse.de>,
	Roland Scheidegger <sroland@vmware.com>,
	Zack Rusin <zackr@vmware.com>,
	Christian Gmeiner <christian.gmeiner@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Rob Herring <robh+dt@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	"David S . Miller" <davem@davemloft.net>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Lucas Stach <l.stach@pengutronix.de>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Ilia Mirkin <imirkin@alum.mit.edu>,
	Qing Zhang <zhangqing@loongson.cn>, Li Yi <liyi@loongson.cn>,
	suijingfeng <suijingfeng@loongson.cn>,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Randy Dunlap <rdunlap@infradead.org>,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v7 1/7] drm/lsdc: add drm driver for loongson display controller
Date: Tue, 15 Feb 2022 11:28:33 +0800	[thread overview]
Message-ID: <14340eb2-2557-e6f1-9252-8533f5a814df@189.cn> (raw)
In-Reply-To: <20220214101031.kerresldiuopil6l@houat>


On 2022/2/14 18:10, Maxime Ripard wrote:
> On Sun, Feb 13, 2022 at 10:16:43PM +0800, Sui Jingfeng wrote:
>> From: suijingfeng <suijingfeng@loongson.cn>
>>
>> There is a display controller in loongson's LS2K1000 SoC and LS7A1000
>> bridge chip, the DC is a PCI device in those chips. It has two display
>> pipes but with only one hardware cursor. Each way has a DVO interface
>> which provide RGB888 signals, vertical & horizontal synchronisations,
>> data enable and the pixel clock. Each CRTC is able to scanout from
>> 1920x1080 resolution at 60Hz. The maxmium resolution is 2048x2048
>> according to the hardware spec.
>>
>> Loongson display controllers are simple which require scanout buffers
>> to be physically contiguous. LS2K1000 is a SOC, Only system memory is
>> available. Therefore CMA helper based driver is intended to be use,
>> although it is possible to use VRAM helper based solution by carving
>> out part of system memory as VRAM.
>>
>> On LS7A1000/LS7A2000 bridge chip, the DC is equipped with a dedicated
>> video memory which is typically 64MB or more. In this case, VRAM helper
>> based solution which scanout from local VRAM is reconmended to use.
>> It is reliable to use for massive production, but CMA based helper
>> solution is still usable on ls7a1000 and ls7a2000, at the price of
>> the CRTC must access the FB in RAM through the PCIe bus and HT3.0 bus.
>> This causes continuous traffic on the bus regardless of whether the FB
>> image is updating or not. Sadly, it suffer from screen flickering under
>> RAM pressure on LS7A1000. Luckily, It show extremely good condition on
>> LS7A2000 even under stressapptest, Maybe the hardware engineer resolve
>> this issue. Integrating two distict helpers based driver into one piece
>> allow code sharing.
>>
>> We have also implemented demage update on top of CMA helper which copy
>> the demaged region from the shadow framebuffer in system RAM to the real
>> framebuffer in VRAM manually. This is intend to overcome the screen
>> flicking issue on LS7A1000, but the performance is not good.
>> Using "lsdc.dirty_update=1" in the kernel commmand line if you would like
>> to have a try.
>>
>> For LS7A1000, there are 4 dedicated GPIOs whose control register is
>> located at the DC register space, They are used to emulate two way i2c.
>> One for DVO0, another for DVO1. This is the reason why this driver is
>> not switch to drm bridge framework yet. LS2K1000 and LS2K0500 SoC don't
>> have such GPIO hardwared, they grab i2c adapter from other module,
>> either general purpose GPIO emulated i2c or hardware i2c adapter.
>> Drm bridge and drm panel driver for the external encoder is suitable for
>> those SoC. We have already implemented this on our downstream 4.19.190
>> kernel. But due to the GPIO, PWM and I2C device driver support for
>> LS2K1000 is not upstreamed yet, this driver still can be use to bring
>> the graphic environment up by providing display timings or similar things
>> in the device tree.
>>
>> The DC in LS7A1000 has only one hardware cursor, we simply let the two
>> CRTC share it. The DC in LS7A2000 have two cursor, two built-in hdmi
>> encoder and one transparent vga encoder and more, surport for LS7A2000
>> is on the way. In short, we have built-in gpio emulated i2c support,
>> we also have hardware cursor support. LS7A2000 The kind of tiny drivers
>> in drm/tiny is not suitable for us.
>>
>>      +------+            +-----------------------------------+
>>      | DDR4 |            |  +-------------------+            |
>>      +------+            |  | PCIe Root complex |   LS7A1000 |
>>         || MC0           |  +--++---------++----+            |
>>    +----------+  HT 3.0  |     ||         ||                 |
>>    | LS3A4000 |<-------->| +---++---+  +--++--+    +---------+   +------+
>>    |   CPU    |<-------->| | GC1000 |  | LSDC |<-->| DDR3 MC |<->| VRAM |
>>    +----------+          | +--------+  +-+--+-+    +---------+   +------+
>>         || MC1           +---------------|--|----------------+
>>      +------+                            |  |
>>      | DDR4 |          +-------+   DVO0  |  |  DVO1   +------+
>>      +------+   VGA <--|ADV7125|<--------+  +-------->|TFP410|--> DVI/HDMI
>>                        +-------+                      +------+
>>
>> The above picture give a simple usage of LS7A1000, note that the encoder
>> is not necessary adv7125 or tfp410, it is a choice of the downstream board
>> manufacturer. Other candicate encoders can be ch7034b, sil9022 and ite66121
>> lt8618 etc. Besides, the DC in both ls2k1000 and ls7k1000 has the same of
>> PCI vendor id and pci device id. Both is 0x0014:0x7a06, the reverison id
>> is also same. This is the firmware engineer's mistake, but such firmware
>> and various boards ship with such firmware already released. We choose to
>> deduce the chip's identification from information provided by device tree.
>> For lsdc, there is only a 1:1 mapping of encoders and connectors.
>>
>> v2: fixup warnings reported by kernel test robot
>>
>> v3: fix more grammar mistakes in Kconfig reported by Randy Dunlap and give
>>      more details about lsdc.
>>
>> v4:
>>     1) Add dts required and explain why device tree is required.
>>     2) Give more description about lsdc and vram helper base driver.
>>     3) Fix warnings reported by kernel test robot.
>>     4) Introduce stride_alignment member into struct lsdc_chip_desc, the
>>        stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500.
>>        But ls7a2000 improve it to 32 bytes, for extend the support for the
>>        device on coming
>>
>> v5:
>>     1) using writel and readl replace writeq and readq, to fix kernel test
>>        robot report build error on other archtecture
>>     2) set default fb format to XRGB8888 at crtc reset time.
>>     3) fix typos.
>>
>> v6:
>>     1) Explain why we are not switch to drm dridge subsystem on ls2k1000.
>>     2) Explain why tiny drm driver is not suitable for us.
>>     3) Give a short description of the trival dirty uppdate implement based
>>        on CMA helper.
>>     4) code clean up
>>
>> v7:
>>     1) Remove select I2C_GPIO and I2C_LS2X in Kconfig, it is not ready now
>>     2) Licensing issues are fixed suggested by Krzysztof Kozlowski.
>>     3) lsdc_pixpll_print() is removed, part of it move to debugfs.
>>     4) Set prefer_shadow to true if vram based driver is in using.
>>     5) Replace double blank lines with single line in all files
>>     6) Verbose cmd line parameter is replaced with drm_dbg()
>>     7) All warnnings reported by ./scripts/checkpatch.pl --strict are fixed
>>     8) Get edid from dtb support is removed as suggested by Maxime Ripard
>>     9) Fix typos and various improvement
> you *need* to have a DT bindings description

Ok, I know that, it takes some time to document it though.


  parent reply	other threads:[~2022-02-15  3:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-13 14:16 [PATCH v7 0/7] drm/lsdc: add drm driver for loongson display controller Sui Jingfeng
2022-02-13 14:16 ` [PATCH v7 1/7] " Sui Jingfeng
2022-02-14 10:10   ` Maxime Ripard
2022-02-14 10:50     ` Sui Jingfeng
2022-02-16 14:22       ` Maxime Ripard
2022-02-15  3:28     ` Sui Jingfeng [this message]
2022-02-13 14:16 ` [PATCH v7 2/7] MIPS: Loongson: ls7a-pch.dtsi: add has_dedicated_vram property Sui Jingfeng
2022-02-13 14:16 ` [PATCH v7 3/7] MIPS: Loongson: introduce dts for ls3A4000 evaluation board Sui Jingfeng
2022-02-13 14:16 ` [PATCH v7 4/7] MIPS: Loongson: introduce dts for lemote A1901 3a4000 motherboard Sui Jingfeng
2022-02-13 14:16 ` [PATCH v7 5/7] MIPS: Loongson: ls2k1000: add the display controller device node Sui Jingfeng
2022-02-13 14:16 ` [PATCH v7 6/7] MIPS: Loongson: Add dts for ls2k1000 pai evaluation board Sui Jingfeng
2022-02-13 14:16 ` [PATCH v7 7/7] MAINTAINERS: add maintainers for DRM LSDC driver Sui Jingfeng
2022-02-13 23:12   ` Joe Perches
2022-02-14  1:18     ` Sui Jingfeng
2022-02-14  1:38     ` Sui Jingfeng
2022-02-14  5:54 ` [PATCH v7 0/7] drm/lsdc: add drm driver for loongson display controller Jiaxun Yang
2022-02-14 10:07   ` Sui Jingfeng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14340eb2-2557-e6f1-9252-8533f5a814df@189.cn \
    --to=15330273260@189.cn \
    --cc=airlied@linux.ie \
    --cc=andrey.zhizhikin@leica-geosystems.com \
    --cc=christian.gmeiner@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=daniel@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imirkin@alum.mit.edu \
    --cc=jiaxun.yang@flygoat.com \
    --cc=krzk@kernel.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=liyi@loongson.cn \
    --cc=lkp@intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maxime@cerno.tech \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sroland@vmware.com \
    --cc=suijingfeng@loongson.cn \
    --cc=tsbogend@alpha.franken.de \
    --cc=tzimmermann@suse.de \
    --cc=zackr@vmware.com \
    --cc=zhangqing@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox