drm/rp1/rp1_dpi: Move Composite Sync generation into the kernel

[njhollinghurst]

Move RP1 DPI's PIO-assisted Composite Sync generation code, previously released as a separate utility, into the kernel driver. There are 3 variants for progressive, generic interlaced and TV- style interlaced CSync, alongside the existing VSync fixup.

Check that all of GPIOs 1-3 are mapped to DPI, so PIO won't try to snoop on a missing output, or override another device's pins.

Add "force-csync" as both an OF property and a module parameter, for convenience of testing, as few tools set DRM_MODE_FLAG_CSYNC.

[pelwell]

I may go through the body of the patch later, but I think the initialisation stuff would be nicer if you invert the logic and have a bitmask of outstanding GPIOs, initialised to 0x7 (or 0xe if you prefer), clearing the bits as they are found.

[njhollinghurst]

Any views about the OF property and module parameter "force-csync"?

DRM_MODE_FLAG_CSYNC is difficult to use. DRM TV mode helper code and command-line mode parser don't set it even for "PAL" and "NTSC" modes. panel-timings can't set it. Neither can utilities like kmstest. About the only reliable way it could be set would be a custom mode-list or dummy EDID. Although the EDID flag (and, I presume, the DRM one) defines it to mean CSync-on-HSync or CSync-on-Green (which doesn't map perfectly to RP1 hardware, or to VC4).

So an alternative mechanism to enable Composite Sync over DEN arguably needed. I'm not sure we need both OF and module properties? The former could be set by a dtparam. The latter could be changed at runtime.

[pelwell]

I have no problem with the idea of the DT property (we're missing an implementation of the overlay parameter to set it), but if you are happy with csync being a system-wide setting then you could just make the override add the module parameter - any string assigned to the bootargs of /chosen is appended, e.g. from the audremap overlays:

	fragment@1 {
		target = <&chosen>;
		__overlay__  {
			bootargs = "snd_bcm2835.enable_headphones=1";
		};
	};

[njhollinghurst]

Ah yes, I had forgotten that trick.
I think I'll leave them both in for now (as with "default_bus_fmt") but might yet remove the OF one.
I think this is just about ready to squash and de-Draft.

[6by9]

I see nothing too untoward, although upstreaming those changes is going to be almost impossible. Happy to kick that one into the long grass though.

[njhollinghurst]

I think I'll remove the OF property anyway, as in theory it would still need documenting.

And I don't propose to check in any overlay changes, so as not to raise issues of VC4 compatibility -- not now anyway!

[igorpecovnik]

K6.14.y compilation breaks with:

   drivers/gpu/drm/rp1/rp1-dpi/rp1_dpi_pio.c:599:5: error: conflicting types for 'rp1dpi_pio_start'; have 'int(struct rp1_dpi *, const struct drm_display_mode *)'
     599 | int rp1dpi_pio_start(struct rp1_dpi *dpi, const struct drm_display_mode *mode)
         |     ^~~~~~~~~~~~~~~~
   In file included from drivers/gpu/drm/rp1/rp1-dpi/rp1_dpi_pio.c:28:
   drivers/gpu/drm/rp1/rp1-dpi/rp1_dpi.h:93:5: note: previous declaration of 'rp1dpi_pio_start' with type 'int(struct rp1_dpi *, const struct drm_display_mode *, bool)' {aka 'int(struct rp1_dpi *, const struct drm_display_mode *, _Bool)'}
      93 | int rp1dpi_pio_start(struct rp1_dpi *dpi, const struct drm_display_mode *mode,
         |     ^~~~~~~~~~~~~~~~
     CC      net/ipv4/igmp.o
   make[8]: *** [scripts/Makefile.build:222: drivers/gpu/drm/rp1/rp1-dpi/rp1_dpi_pio.o] Error 1
   make[7]: *** [scripts/Makefile.build:472: drivers/gpu/drm/rp1/rp1-dpi] Error 2
   make[6]: *** [scripts/Makefile.build:472: drivers/gpu/drm/rp1] Error 2
   make[5]: *** [scripts/Makefile.build:472: drivers/gpu/drm] Error 2
   make[4]: *** [scripts/Makefile.build:472: drivers/gpu] Error 2

Full logs: https://paste.armbian.com/afuqupofuy

[pelwell]

You must have a config where CONFIG_RP1_DPI is enabled but not CONFIG_RP1_PIO. We'll patch it up.

[igorpecovnik]

You must have a config where CONFIG_RP1_DPI is enabled but not CONFIG_RP1_PIO. We'll patch it up.

Quite possible, will enable. Still this needs to be done different.

Thanks for prompt response!

[pelwell]

See #6851. It will be forward-ported to the newer kernels once it is merged to 6.12.