The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221118224540.619276-44-uwe@kleine-koenig.org

The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221118224540.619276-43-uwe@kleine-koenig.org

The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221118224540.619276-42-uwe@kleine-koenig.org

The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221118224540.619276-41-uwe@kleine-koenig.org

The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221118224540.619276-40-uwe@kleine-koenig.org

The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221118224540.619276-39-uwe@kleine-koenig.org

Ignoring errors from devm_clk_get() is wrong. To handle not all platforms
having an axi clk use devm_clk_get_optional() instead and do proper error
handling.

Also the clk API handles NULL as a dummy clk (which is also returned by
devm_clk_get_optional() if there is no clk) so there is no need to check
for NULL before calling clk_prepare_enable() or its counter part.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200720153254.18071-1-u.kleine-koenig@pengutronix.de

devm_regulator_get_enable_optional() function returns 0 on success, so
use it for the check if function succeeded instead of the -ENODEV value.

Fixes: 429e8706 ("drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()")
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NNeil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
[narmstrong: s/succeeded/succeeded/ in commit message]
Link: https://patchwork.freedesktop.org/patch/msgid/20230109220033.31202-1-m.szyprowski@samsung.com

Add support for the 1080x2400 Visionox VTDR6130 AMOLED DSI panel
found on the Qualcomm SM8550 MTP board.

By default the the panel is configured to work with DSI compressed
streams, but can work in uncompressed video mode since 1080x2400 in
RGB888 fits in the 4 DSI lanes bandwidth.

While display compression is preferred for performance and power
reasons, let's start with the uncompressed video mode support and
add the DSC support later on.
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
[narmstrong: moved drm/display/ include file before drm/drm_]
Link: https://patchwork.freedesktop.org/patch/msgid/20230103-topic-sm8550-upstream-vtdr6130-panel-v2-2-dd6200f47a76@linaro.org

Document the 1080x2400 Visionox VTDR6130 AMOLED DSI Panel bindings.
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
[narmstrong: drop last, redundant "bindings" in subject]
Link: https://patchwork.freedesktop.org/patch/msgid/20230103-topic-sm8550-upstream-vtdr6130-panel-v2-1-dd6200f47a76@linaro.org

The VEC is able to output progressive analog modes, but the driver has
never set the proper bit to do so.
Signed-off-by: NMateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-15-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

The back porch timings were correct, only the sync offset was wrong.
Correct timing is now reported for 1080i and 576i, but the h offset is
incorrect for 480i for non-obvious reasons.

Fixes: fb10dc45 ("drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes")
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-14-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

This commit fixes vertical timings of the VEC (composite output) modes
to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R
standards.

Previous timings were actually defined as 502 and 601 lines, resulting
in non-standard 62.69 Hz and 52 Hz signals being generated,
respectively.

Changes to vc4_crtc.c have also been made, to make the PixelValve
vertical timings accurately correspond to the DRM modeline in interlaced
modes. The resulting VERTA/VERTB register values have been verified
against the reference values set by the Raspberry Pi firmware.
Signed-off-by: NMateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-13-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

The HVS_PIXEL_ORDER_xxx defines apply to specific HVS_PIXEL_FORMAT_xxx
modes, so add comments to make this obvious.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-12-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

The hardware supports the 332 8bpp and 4:4:4:4 16bpp formats,
but the table of supported formats didn't include them.
Add them in.

In theory they are supported for T-format as well as linear,
but without a way to test them just add them as linear for now.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-11-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

pixel_order is used for the earlier versions of the HVS, so is
redundant on the 10:10:10:2 and 10bit YUV formats that are only
supported on HVS5.
Remove the assignment from the table to avoid confusion.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-10-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

vc4_plane_mode_set for HVS5 was using pixel_order unless pixel_order_hvs5
was non-zero, except 0 is a valid value for the pixel_order.

Specify pixel_order_hvs5 for all formats and remove the conditional.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-9-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

atomic_flush will be called for each CRTC even if they aren't enabled.

The whole code we have there will thus run without a properly affected
channel, which can then result in all sorts of weird behaviour.
Reviewed-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-8-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

HVS5 supports the 210101010 RGB[A|X] formats, but they were
missing from the DRM to HVS mapping list, so weren't available.
Add them in.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-7-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

Same as the xRGB8888 formats, HVS5 has managed to swap the colour
channels for the xRGB1555 formats as well. Add the relevant
config for pixel_order_hvs5.

Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-6-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

Adds the zpos property to all planes, and creates the dlist
by placing the fragments in the correct order based on zpos.
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-5-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

HVS5 has moved the interrupt enable bits around within the
DISPCTRL register, therefore the configuration has to be updated
to account for this.

Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-4-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

The bit used for SCALER_DISPBKGND_AUTOHS in SCALER_DISPBKGNDX
has been repurposed on HVS5 to configure whether a display can
win back-to-back arbitration wins for the COB.

This is not desirable, therefore only select this bit on HVS4,
and explicitly clear it on HVS5.

Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-3-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

The HVS can change AXI request mode based on how full the COB
FIFOs are.
Until now the vc4 driver has been relying on the firmware to
have set these to sensible values.

With HVS channel 2 now being used for live video, change the
panic mode for all channels to be explicitly set by the driver,
and the same for all channels.

Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-2-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

The HVS Composite Output Buffer (COB) is the memory used to
generate the output pixel data.
Until now the vc4 driver has been relying on the firmware to
have set these to sensible values.

In testing triple screen support it has been noted that only
1 line was being assigned to HVS channel 2. Whilst that is fine
for the transposer (TXP), and indeed needed as only some pixels
have an alpha channel, it is insufficient to run a live display.

Split the COB more evenly between the 3 HVS channels.

Fixes: c54619b0 ("drm/vc4: Add support for the BCM2711 HVS5")
Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-1-1f8e0770798b@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

Many panel drivers define dsi_dcs_write_seq() and dsi_generic_write_seq()
macros to send DCS commands and generic write packets respectively, with
the payload specified as a list of parameters instead of using arrays.

There's already a macro for the former, introduced by commit 2a9e9daf
("drm/mipi-dsi: Introduce mipi_dsi_dcs_write_seq macro") so drivers can be
changed to use that. But there isn't one yet for the latter, let's add it.
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230102202542.3494677-2-javierm@redhat.com

Change made using a `clang-format -i include/drm/drm_mipi_dsi.h` command.
Suggested-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230102202542.3494677-1-javierm@redhat.com

Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_files() function, which center the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on hdlcd_drm_bind(),
before drm_dev_register().
Signed-off-by: NMaíra Canal <mcanal@igalia.com>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NMaíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20221226155029.244355-4-mcanal@igalia.com

Replace the use of drm_debugfs_create_files() with the new
drm_debugfs_add_file() function, which center the debugfs files
management on the drm_device instead of drm_minor. Moreover, remove the
debugfs_init hook and add the debugfs files directly on gud_probe(),
before drm_dev_register().
Signed-off-by: NMaíra Canal <mcanal@igalia.com>
Acked-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NMaíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20221226155029.244355-3-mcanal@igalia.com

Replace the combination of bpp and depth with a single color-mode
argument. Handle special cases in simpledrm and ofdrm. Hard-code
XRGB8888 as fallback format for cases where no given format works.

The color-mode argument accepts the same values as the kernel's video
parameter. These are mostly bpp values between 1 and 32. The exceptions
are 15, which has a color depth of 15 and a bpp value of 16; and 32,
which has a color depth of 24 and a bpp value of 32.

v4:
	* add back lost test for bpp_specified (Maira)
	* add Fixes tag (Daniel)
v3:
	* fix ofdrm build (Maxime)
v2:
	* minimize changes (Daniel)
	* use drm_driver_legacy_fb_format() (Daniel)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Tested-by: Maíra Canal <mcanal@igalia.com> # vc4 and vkms
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Fixes: 37c90d58 ("drm/fb-helper: Fix single-probe color-format selection")
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230106112324.22055-1-tzimmermann@suse.de

Now as all drivers stopped calling drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() it is safe to remove them complelely.
Rename our internal helpers to remove the underscore prefix.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-8-dmitry.baryshkov@linaro.org

The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-7-dmitry.baryshkov@linaro.org

The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-6-dmitry.baryshkov@linaro.org

The functionality of drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() is provided automatically by the
drm_kms_poll helpers. Stop calling these functions manually.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
[narmstrong: removed now unused kms var in dcss_dev_suspend|resume()]
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-5-dmitry.baryshkov@linaro.org

Use drm_connector's helpers enable_hpd and disable_hpd to enable and
disable HPD automatically by the means of drm_kms_helper_poll_*
functions. As the drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() functions are now unused, replace
them with stubs to ease driver migration.

Enabling the HPD from drm_bridge_connector_init() can happen too early,
before the driver is prepared to handle HPD events. As the
drm_bridge_connector_enable_hpd() is empty anyway, drop this call
anyway.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-4-dmitry.baryshkov@linaro.org

Introduce two drm_connector_helper_funcs: enable_hpd() and disable_hpd().
They are called by drm_kms_helper_poll_enable() and
drm_kms_helper_poll_disable() (and thus drm_kms_helper_poll_init() and
drm_kms_helper_poll_fini()) respectively.

This allows DRM drivers to rely on drm_kms_helper_poll for enabling and
disabling HPD detection rather than doing that manually.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-3-dmitry.baryshkov@linaro.org

Merge drm_kms_helper_poll_disable() and drm_kms_helper_poll_fini() code
into a common helper function.
Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221102180705.459294-2-dmitry.baryshkov@linaro.org

It's a bit a FAQ, and we really can't claim to be the authoritative
source for allocating these numbers used in many standard extensions
if we tell closed source or vendor stacks in general to go away.

Iirc this was already clarified in some vulkan discussions, but I
can't find that anywhere anymore. At least not in a public link.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Neil Trevett <ntrevett@nvidia.com>
Acked-by: NDaniel Stone <daniels@collabora.com>
Acked-by: NMaxime Ripard <maxime@cerno.tech>
Acked-by: NDavid Airlie <airlied@gmail.com>
Acked-by: NMarek Olšák <maraeo@gmail.com>
Acked-by: NBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Acked-by: NJason Ekstrand <jason.ekstrand@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123192437.1065826-1-daniel.vetter@ffwll.ch

Commit 5ea6b170 ("drm/panel: Add prepare_prev_first flag to
drm_panel") introduced an access to the bridge pointer in the
devm_drm_panel_bridge_add_typed() function.

However, due to the unusual ERR_PTR check when getting that pointer, the
pointer access is done even though the pointer might be an error
pointer.

Rework the function for a more traditional design that will return
immediately if it gets an ERR_PTR so that we never access the pointer in
that case.

Fixes: 5ea6b170 ("drm/panel: Add prepare_prev_first flag to drm_panel")
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NDan Carpenter <error27@gmail.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20230102120123.19062-1-maxime@cerno.tech
Link: https://patchwork.freedesktop.org/patch/msgid/20230102120123.19062-1-maxime@cerno.tech

Add a paragraph explaining that the default behavior for areas which
are not covered by planes or where planes are blending with the CRTC
background, is black.

This is alluded to in the "pixel blend mode" property docs, but not
called out explicitly.
Reviewed-by: NSimon Ser <contact@emersion.fr>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230103152738.1213785-1-sean@poorly.run