[PATCH 00/28] OpenChrome DRM for Linux 5.20
Thomas Zimmermann
tzimmermann at suse.de
Mon Jun 27 07:37:57 UTC 2022
Hi Kevin
Am 24.06.22 um 22:26 schrieb Kevin Brace:
> From: Kevin Brace <kevinbrace at bracecomputerlab.com>
>
> Hi Dave and Daniel,
>
> This is my first attempt (this is not a RFC posting) in trying to get
> OpenChrome DRM pulled in for Linux 5.20.
First of all, thank you so much for working on this.
> I started to work on this seriously around the summer of 2017, so it has
> been a long journey.
> I know that the code is not quite perfect, but I have done as much work
> as I can do on my own, and I now think that I should post the code on
> dri-devel mailing list for other people to take a look at it.
I had a brief look over the patches. Even though the code looks fairly
rough in places, I think we should get this driver merged ASAP. Once
merged, cleanups become *a lot* easier.
> Whether or not the code itself works or not, no, OpenChrome DRM is not
> some vaporware, and the code reliability is comparable to the existing
> OpenChrome DDX UMS code path.
> The code reliability is more than good enough to the point where I utilize
> the module almost every time I work on developing the code.
> I am aware that the hardware (silicon) is quite old by today's standards,
> so not too many people "still" (the word one open source software focused
> journalist often uses to describe greater than 5 year old computer
> hardware) own the VIA silicon hardware to actually test the code
> themselves.
I wanted to test the patches (with that other additional patch), but
they don't build with the current DRM development tree.
> The current code is developed against drm-next branch
> drm-next-2022-06-03-1 tag.
This will go through drm-misc-next, presumably. You need to rebase on
top of that branch. Please don't merge but rebase, so that you actually
have all required changes in the next patchset. I've found that at least
DRM's Kconfig file misses a change and that <linux/pci_ids.h> doesn't
contain all necessary PCI ids.
This should be the next step.
> The current iteration of the code has no support for acceleration.
> It is currently a mode setting only DRM module.
> Even if the code is pulled into the Linux kernel tree, I will consider
> the code experimental until at least 2D acceleration is implemented for
> all supported devices.
Just forget about 2d acceleration (aka blitters). Daniel did a write-up
about the specific problems of 2d acceleration at [1].
(There's also video acceleration, which is a different story.)
> Because of this, the DRM module requires via.modeset=1 to be added to
> Linux kernel boot option line for it to function, and I intend to keep
> this arrangement in place until at least 2D acceleration is fully
> supported.
Don't do that. Enable modesetting from day 1. You want to get the driver
out to users ASAP. Otherwise, it'll take another 5 years.
We plenty of options to disable your driver on systems where it fails.
> As a result, I think the code is fairly low risk to be pulled into the
> Linux kernel tree.
Exactly.
> The current module version is 3.5.2, but when the code is about to
> be pulled into the kernel tree, I will like to up the version to 4.0.0.
> This is because James Simmons era OpenChrome DRM used version number
> 3.0.x, but the current OpenChrome DRM uAPI implementation is different
> from his implementation, so I will like to assign a new major version
> (i.e., 4) so that DDX can distinguish the old and new OpenChrome DRM.
> The current uAPI has no backward compatibility with the older DRI1 based
> implementation, although some remnants of old DRI1 based uAPI still needs
> to be there inside via_drm.h for XvMC based libraries on the DDX side to
> properly compile.
What is the DDX required for? Would the regular X11 modesetting driver
work as well?
> It is my intention to replace the old DRI1 based VIA DRM located at
> drivers/gpu/drm/via/ with OpenChrome DRM at the same location.
> As I indicated previously, I do not wish to get pulled into the staging
> area of the kernel tree.
DRM is not allowed in staging.
For the old via driver, I think we need a better apprach. IMHO it would
be preferable to put the new driver into via/ but keep the old driver
there as well. A build option would control which is being used.
Best regards
Thomas
[1] https://blog.ffwll.ch/2018/08/no-2d-in-drm.html
> I personally will like to have the option of porting the code to
> BSD someday, however, the I2C bus access module (via_i2c.c) is GPL
> based, so the DRM module license type is GPL (everything else is MIT
> license based), for now.
> I hope to replace this module someday with equivalent functionality
> code that will be MIT license based.
> I hope the uAPI variable types are compatible with BSD (please give
> me advise on this since I do not know too much about this) since James
> Simmons brought this up back in 2013 when he posted the code as RFC.
>
> https://lists.freedesktop.org/archives/dri-devel/2013-June/039594.html
> https://lists.freedesktop.org/archives/dri-devel/2013-June/040811.html
>
>
> Features:
>
> - Supports 12 different generations of VIA Technologies Chrome based
> integrated graphics (CLE266 / KM400 / K8M800 / P4M800 Pro / PM800 /
> P4M890 / K8M890 / P4M900 / CX700 / VX800 / VX855 / VX900 chipset) and
> their variants
> - Support for DAC (VGA), LVDS flat panel, DVI (CX700 / VX800 chipset
> integrated, VX900 chipset integrated, and Silicon Image SiI164 /
> VIA Technologies VT1632(A) DVI transmitter), and HDMI (VX900H chipset
> integrated)
> - Support for standby resume (ACPI S3 State)
> - Support for dual head operation
> - Supports atomic mode setting (implementation might still be incomplete
> especially around gamma correction / palette initialization)
> - Utilizes GEM / TTM for memory management
> - Utilizes DRM FB Helper for FBDEV emulation
>
>
> Known issues:
>
> - via_lvds.c gives out 3 unused function warnings (willing to delete
> the offending functions since they are not used)
> - Gamma correction / palette initialization code is still legacy KMS
> based (Daniel, how do I convert it for atomic mode setting?)
> - uAPI might not be quite right (Do I need something like
> DRM_IOCTL_VIA_GEM_DESTROY or DRM_IOCTL_VIA_GEM_FREE call to pair it
> against DRM_IOCTL_VIA_GEM_CREATE?)
>
>
> Code repository:
> https://cgit.freedesktop.org/openchrome/drm-openchrome/
>
> Current bleeding edge branch (drm-next-5.20 branch):
> https://cgit.freedesktop.org/openchrome/drm-openchrome/?h=drm-next-5.20
>
> Current bleeding edge branch (drm-next-5.20 branch) code location:
> https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/via?h=drm-next-5.20
> https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/include/uapi/drm?h=drm-next-5.20
>
> Obviously, I do not expect to get the code pulled in on my first try,
> but if other people can point out what I need to improve, I will try to
> improve the code so that I can get the code pulled in as soon as possible.
> Personally, I will like the code to be pulled in for Linux 5.20, but I
> sort of expect the next release after 5.20 is more likely.
>
> Regards,
>
> Kevin Brace
> Brace Computer Laboratory blog
> https://bracecomputerlab.com
>
>
> ---
> Kevin Brace (28):
> drm/via: Add via_3d_reg.h
> drm/via: Add via_crtc_hw.h
> drm/via: Add via_disp_reg.h
> drm/via: Add via_drv.h
> drm/via: Add via_regs.h
> drm/via: Add via_crtc.c
> drm/via: Add via_crtc_hw.c
> drm/via: Add via_cursor.c
> drm/via: Add via_dac.c
> drm/via: Add via_display.c
> drm/via: Add via_drv.c
> drm/via: Add via_encoder.c
> drm/via: Add via_hdmi.c
> drm/via: Add via_i2c.c
> drm/via: Add via_init.c
> drm/via: Add via_ioctl.c
> drm/via: Add via_lvds.c
> drm/via: Add via_object.c
> drm/via: Add via_pll.c
> drm/via: Add via_pm.c
> drm/via: Add via_sii164.c
> drm/via: Add via_tmds.c
> drm/via: Add via_ttm.c
> drm/via: Add via_vt1632.c
> drm/via: Add via_drm.h
> drm/via: Add Kconfig
> drm/via: Add Makefile
> drm/via: Modify DRM main Makefile to be able to build OpenChrome DRM
>
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/via/Kconfig | 10 +
> drivers/gpu/drm/via/Makefile | 26 +
> drivers/gpu/drm/via/via_3d_reg.h | 1863 ++++++++++++++++++++++
> drivers/gpu/drm/via/via_crtc.c | 2324 ++++++++++++++++++++++++++++
> drivers/gpu/drm/via/via_crtc_hw.c | 91 ++
> drivers/gpu/drm/via/via_crtc_hw.h | 1048 +++++++++++++
> drivers/gpu/drm/via/via_cursor.c | 419 +++++
> drivers/gpu/drm/via/via_dac.c | 504 ++++++
> drivers/gpu/drm/via/via_disp_reg.h | 513 ++++++
> drivers/gpu/drm/via/via_display.c | 125 ++
> drivers/gpu/drm/via/via_drv.c | 313 ++++
> drivers/gpu/drm/via/via_drv.h | 437 ++++++
> drivers/gpu/drm/via/via_encoder.c | 173 +++
> drivers/gpu/drm/via/via_hdmi.c | 719 +++++++++
> drivers/gpu/drm/via/via_i2c.c | 209 +++
> drivers/gpu/drm/via/via_init.c | 1300 ++++++++++++++++
> drivers/gpu/drm/via/via_ioctl.c | 122 ++
> drivers/gpu/drm/via/via_lvds.c | 1420 +++++++++++++++++
> drivers/gpu/drm/via/via_object.c | 324 ++++
> drivers/gpu/drm/via/via_pll.c | 263 ++++
> drivers/gpu/drm/via/via_pm.c | 187 +++
> drivers/gpu/drm/via/via_regs.h | 296 ++++
> drivers/gpu/drm/via/via_sii164.c | 563 +++++++
> drivers/gpu/drm/via/via_tmds.c | 714 +++++++++
> drivers/gpu/drm/via/via_ttm.c | 168 ++
> drivers/gpu/drm/via/via_vt1632.c | 583 +++++++
> include/uapi/drm/via_drm.h | 309 ++++
> 28 files changed, 15024 insertions(+)
> create mode 100644 drivers/gpu/drm/via/Kconfig
> create mode 100644 drivers/gpu/drm/via/Makefile
> create mode 100644 drivers/gpu/drm/via/via_3d_reg.h
> create mode 100644 drivers/gpu/drm/via/via_crtc.c
> create mode 100644 drivers/gpu/drm/via/via_crtc_hw.c
> create mode 100644 drivers/gpu/drm/via/via_crtc_hw.h
> create mode 100644 drivers/gpu/drm/via/via_cursor.c
> create mode 100644 drivers/gpu/drm/via/via_dac.c
> create mode 100644 drivers/gpu/drm/via/via_disp_reg.h
> create mode 100644 drivers/gpu/drm/via/via_display.c
> create mode 100644 drivers/gpu/drm/via/via_drv.c
> create mode 100644 drivers/gpu/drm/via/via_drv.h
> create mode 100644 drivers/gpu/drm/via/via_encoder.c
> create mode 100644 drivers/gpu/drm/via/via_hdmi.c
> create mode 100644 drivers/gpu/drm/via/via_i2c.c
> create mode 100644 drivers/gpu/drm/via/via_init.c
> create mode 100644 drivers/gpu/drm/via/via_ioctl.c
> create mode 100644 drivers/gpu/drm/via/via_lvds.c
> create mode 100644 drivers/gpu/drm/via/via_object.c
> create mode 100644 drivers/gpu/drm/via/via_pll.c
> create mode 100644 drivers/gpu/drm/via/via_pm.c
> create mode 100644 drivers/gpu/drm/via/via_regs.h
> create mode 100644 drivers/gpu/drm/via/via_sii164.c
> create mode 100644 drivers/gpu/drm/via/via_tmds.c
> create mode 100644 drivers/gpu/drm/via/via_ttm.c
> create mode 100644 drivers/gpu/drm/via/via_vt1632.c
> create mode 100644 include/uapi/drm/via_drm.h
>
> --
> 2.35.1
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220627/5aa0c89b/attachment.sig>
More information about the dri-devel
mailing list