Cleanup downstream lan78xx#7295
Open
nbuchwitz wants to merge 695 commits intoraspberrypi:rpi-6.18.yfrom
Open
Conversation
nbuchwitz
changed the title
nbuchwitz
force-pushed
the
devel/lan78xx-eee
branch
from
bd213ee to
899790f
Compare
With the command line parser now providing the information about the tv mode, use that as the preferred choice for initialising the default of the tv_mode property. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
If you disable HDR metadata, then the hardware should stop sending the infoframe, and that is implemented by the clear_infoframe hook which wasn't implemented. Add it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
See: https://forum.libreelec.tv/thread/24783-tv-avr-turns-back-on-right-after-turning-them-off While the kernel provides a :D flag for assuming device is connected, it doesn't stop this function from being called and generating a cec_phys_addr_invalidate message when hotplug is deasserted. That message provokes a flurry of CEC messages which for many users results in the TV switching back on again and it's very hard to get it to stay switched off. It seems to only occur with an AVR and TV connected but has been observed across a number of manufacturers. The issue started with raspberrypi#4371 and this provides an optional way of getting back the old behaviour Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The intention of the vc4.force_hotplug setting is to ignore hotplug completely. It can be used when a display toggles hotplug when switching AV inputs, going into standby or changing a KVM switch, and some side effect of that is unwanted. It turns out while vc4.force_hotplug currently makes hotplug always read as asserted, that isn't enough to stop drm doing lots of stuff, including re-reading the edid. An example of what drm does with a hotplug deasert/assert and vc4.force_hotplug=1 currently is: https://paste.debian.net/hidden/dc07434b/ That is unwanted. Lets ignore the hotplug interrupt completely so drm is blissfully unaware of the hotplug change. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
There appears to be a requirement for some devices (I'm testing with a 8K VRROOM 40Gbps HDMI switch) for a measable delay between removing the hdmi phy output from the old mode, to enabling the hdmi phy output for the new mode. Without the delay, a mode switch has a small change of getting a permanent 'no signal', which requires a subsequent mode switch or a unplug/replug to redetect. Switching between 4kp24/25/30 modes fails about 5% of time in my testing. Add a delay to make it impossible to switch faster than this. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The body of this function was missing so we don't reset the phy when disabling it. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The current reset code doesn't actually stop the hdmi output. That makes it difficult for displays to handle a mode set. Powering down the PLL does actually remove the hdmi signal and makes mode sets more reliable Signed-off-by: Dom Cobley <popcornmix@gmail.com>
There are no MEDIA_BUS_FMT_* defines for GRB or BRG, and adding them is a pain. Add a DT override to allow setting the order. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Seeing as the HVS can be configured with regard the scaling filter, and DRM now supports selecting scaling filters at a per CRTC or per plane level, we can implement it. Default remains as the Mitchell/Netravali filter, but nearest neighbour is now also implemented. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The documentation says that the TPZ filter can not upscale, and requesting a scaling factor > 1:1 will output the original image in the top left, and repeat the right/bottom most pixels thereafter. That fits perfectly with upscaling a 1x1 image which is done a fair amount by some compositors to give solid colour, and it saves a large amount of LBM (TPZ is based on src size, whilst PPF is based on dest size). Select TPZ filter for images with source rectangle <=1. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The register to enable/disable background fill was being set from atomic flush, however that will be applied immediately and can be a while before the vblank. If it was required for the current frame but not for the next one, that can result in corruption for part of the current frame. Store the state in vc4_hvs, and update it on vblank. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The HVS can accept an arbitrary number of planes, provided that the overall pixel read load is within limits, and the display list can fit into the dlist memory. Now that DRM will support 64 planes per device, increase the number of overlay planes from 16 to 48 so that the dlist complexity can be increased (eg 4x4 video wall on each of 3 displays). Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Instead of having 48 generic overlay planes, assign 32 to the writeback connector so that there is no ambiguity in wlroots when trying to find a plane for composition using the writeback connector vs display. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The transposer/writeback connector should be running with a lower priority, so shouldn't be factored into the load calculations. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
As the writeback connector doesn't have the same realtime constraints of a live display, drop the panic priority for it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The txp block can implement transpose as it writes out the image data, so expose that through the new connector rotation property. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm: vc4: txp: Do not allow 24bpp formats when transposing The hardware doesn't support transposing to 24bpp (RGB888/BGR888) formats. There's no way to advertise this through DRM, so block it from atomic_check instead. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Currently, booting with no hdmi connected has: pi@pi4:~ $ vcgencmd measure_clock hdmi pixel frequency(9)=120010256 frequency(29)=74988280 After connecting hdmi we get: pi@pi4:~ $ vcgencmd measure_clock hdmi pixel frequency(9)=300005856 frequency(29)=149989744 and that persists after disconnecting hdmi I can measure this on a power supply as 10mA@5.2V (52mW). We should always remove clk_set_min_rate requests when we no longer need them. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Whilst BCM2712 does fix using odd horizontal timings, it doesn't work with interlaced modes. Drop the workaround for interlaced modes and revert to the same behaviour as BCM2711. raspberrypi#6281 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
This is a squash of all firmware-kms related patches from previous branches, up to and including "drm/vc4: Set the possible crtcs mask correctly for planes with FKMS" plus a couple of minor fixups for the 5.9 branch. Please refer to earlier branches for full history. This patch includes work by Eric Anholt, James Hughes, Phil Elwell, Dave Stevenson, Dom Cobley, and Jonathon Bell. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fixup firmware-kms after "drm/atomic: Pass the full state to CRTC atomic enable/disable" Prototype for those calls changed, so amend fkms (which isn't upstream) to match. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fixup fkms for API change Atomic flush and check changed API, so fix up the downstream-only FKMS driver. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Make normalize_zpos conditional on using fkms Eric's view was that there was no point in having zpos support on vc4 as all the planes had the same functionality. Can be later squashed into (and fixes): drm/vc4: Add firmware-kms mode Signed-off-by: Dom Cobley <popcornmix@gmail.com> drm/vc4: FKMS: Change of Broadcast RGB mode needs a mode change The Broadcast RGB (aka HDMI limited/full range) property is only notified to the firmware on mode change, so this needs to be signalled when set. raspberrypi/firmware#1580 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> vc4/drv: Only notify firmware of display done with kms fkms driver still wants firmware display to be active Signed-off-by: Dom Cobley <popcornmix@gmail.com> ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. raspberrypi#4447 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: Use new devm_rpi_firmware_get api drm/kms: Add allow_fb_modifiers Signed-off-by: Dom Cobley <popcornmix@gmail.com> drm/vc4: Add async update support for cursor planes Now that cursors are implemented as regular planes, all cursor movements result in atomic updates. As the firmware-kms driver doesn't support asynchronous updates, these are synchronous, which limits the update rate to the screen refresh rate. Xorg seems unaware of this (or at least of the effect of this), because if the mouse is configured with a higher update rate than the screen then continuous mouse movement results in an increasing backlog of mouse events - cue extreme lag. Add minimal support for asynchronous updates - limited to cursor planes - to eliminate the lag. See: raspberrypi#4971 raspberrypi#4988 Signed-off-by: Phil Elwell <phil@raspberrypi.com> drivers/gpu/drm/vc4: Add missing 32-bit RGB formats The missing 32-bit per pixel ABGR and various "RGB with an X value" formats are added. Change sent by Dave Stevenson. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> drm: vc4: Fixup duplicated macro definition in vc4_firmware_kms Both vc4_drv.h and vc4_firmware_kms.c had definitions for to_vc4_crtc. Rename the fkms one to make it unique, and drop the magic define vc4_crtc vc4_kms_crtc define to_vc4_crtc to_vc4_kms_crtc that renamed half the variable and function names in a slightly unexpected way. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fix FKMS for when the YUV chroma planes are different buffers The code was assuming that it was a single buffer with offsets, when kmstest uses separate buffers and 0 offsets for each plane. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: Rename plane related functions The name collide with the Full KMS functions that are going to be made public. Signed-off-by: Maxime Ripard <maxime@cerno.tech> drm/vc4_fkms: Fix up interrupt handler for both 2835/2711 and 2712 2712 has switched from using the SMI peripheral to another interrupt source for the vsync interrupt, so handle both sources cleanly. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: No SMI abuse needed on BCM2712 Since we don't use the (absent) SMI block to create interrupts on BCM2712, there's no need to map any registers. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Testing whether the VideoCore generation we want to mock is vc5 or vc4 worked so far, but will be difficult to extend to support BCM2712 (VC6). Convert to a switch. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The DRM device pointer and the DRM encoder pointer are redundant, since the latter is attached to the former and we can just follow the drm_encoder->dev pointer. Let's remove the drm_device pointer argument. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Some tests will need to retrieve the output that was just allocated by vc4_mock_atomic_add_output(). Instead of making them look them up in the DRM device, we can simply make vc4_mock_atomic_add_output() return an error pointer that holds the allocated output instead of the error code. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The BCM2712 has a simpler pipeline that can only output to a writeback connector and two HDMI controllers. Let's allow our kunit tests to create a mock of that pipeline. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The BCM2712 has a simpler pipeline than the BCM2711, and thus the muxing requirements are different. Create some tests to make sure we get proper muxing decisions. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The current mock planes were just using the regular drm_plane_state, while the driver expect struct vc4_plane_state that subclasses drm_plane_state. Hook the proper implementations of reset, duplicate_state, destroy and atomic_check to create vc4_plane_state. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Some tests will need to find a plane to run a test on for a given CRTC. Let's create a small helper to do that. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
We'll start to add some tests for the plane state logic, so let's create a helper to add a plane to an existing atomic state. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Retain the original compatible strings as fallbacks. See: raspberrypi#7023 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
On pi this was getting set to 0 which was hanging the firmware Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Commit de9e2b3d88af upstream. Currently DIV_ROUND_CLOSEST() is only available for the kernel via include/linux/math.h. Expose it to userland as well by adding __KERNEL_DIV_ROUND_CLOSEST() as a common definition in uapi. Additionally, ensure it allows building ISO C applications by switching from the 'typeof' GNU extension to the ISO-friendly __typeof__. Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260303-rk3588-bgcolor-v8-1-fee377037ad1@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
Commit 4c684596cde4 upstream. Some display controllers can be hardware programmed to show non-black colors for pixels that are either not covered by any plane or are exposed through transparent regions of higher planes. This feature can help reduce memory bandwidth usage, e.g. in compositors managing a UI with a solid background color while using smaller planes to render the remaining content. To support this capability, introduce the BACKGROUND_COLOR standard DRM mode property, which can be attached to a CRTC through the drm_crtc_attach_background_color_property() helper function. Additionally, define a 64-bit ARGB format value to be built with the help of a couple of dedicated DRM_ARGB64_PREP*() helpers. Individual color components can be extracted with desired precision using the corresponding DRM_ARGB64_GET*() macros. Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Diederik de Haas <diederik@cknow-tech.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://patch.msgid.link/20260303-rk3588-bgcolor-v8-2-fee377037ad1@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
When adding the register definitions for the GEN_6D hardware, 6 defines managed to get added twice. Remove that duplication. Fixes: 3ca2940 ("drm/vc4: hvs: Add in support for 2712 D-step.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Since a previous patch introduced the BACKGROUND_COLOR CRTC property, which defaults to solid black, take it into account when programming the hardware. The exact registers used varies between the hardware generations, but is supported by all of them. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The downstream implementation of power management for v3d used a 100ms delay and it has been tested for many years with success. Use the same delay with the runtime PM implementation. Although the shorter 50ms delay is not problematic in RPi 5, it can cause occasional GPU resets on RPi 4 during intensive workloads, due to the overhead of negotiating with the ASB bridge during frequent power domain transitions. Signed-off-by: Maíra Canal <mcanal@igalia.com>
The PHY supports swapping the pairs within a lane, so expose this. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The driver uses a couple of crypto_shash_* functions, which are not always available, potentially leading to build errors: arm-linux-ld: drivers/spi/spi-rp2040-gpio-bridge.o: in function `rp2040_gbdg_block_hash': spi-rp2040-gpio-bridge.c:(.text+0x274): undefined reference to `crypto_shash_update' spi-rp2040-gpio-bridge.c:(.text+0x2c4): undefined reference to `crypto_shash_update' spi-rp2040-gpio-bridge.c:(.text+0x2e4): undefined reference to `crypto_shash_final' spi-rp2040-gpio-bridge.c:(.text+0x2ec): undefined reference to `crypto_shash_digest' spi-rp2040-gpio-bridge.c:(.text+0x2fc): undefined reference to `crypto_shash_update' arm-linux-ld: drivers/spi/spi-rp2040-gpio-bridge.o: in function `rp2040_gbdg_probe': spi-rp2040-gpio-bridge.c:(.text+0x510): undefined reference to `crypto_alloc_shash' Fixes: fe24eda ("spi: Add a driver for the RPI RP2040 GPIO bridge") Signed-off-by: Corubba Smith <corubba@gmx.de>
PHY devices had lack of hwtstamp_get callback even though most of them are tracking configuration info. Introduce new call back to mii_timestamper. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20251124181151.277256-3-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit f467777)
The driver stores configuration information and can technically report it. Implement hwtstamp_get callback to report the configuration. Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Signed-off-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20251124181151.277256-4-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 1cff839)
Some hub hardware does not differentiate pipe direction in the non-periodic split handler, so transfers to the same endpoint index will collide. A simple fix is to limit the non-periodic masquerade only to IN transfers, which are also the most affected by interrupt latency. A recurrence of raspberrypi#2024 Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
nbuchwitz
force-pushed
the
devel/lan78xx-eee
branch
from
899790f to
0d85bf0
Compare
Collaborator
|
@pelwell I'm in favour of removing unneeded downstream code. Are you happy this is okay? |
pelwell
reviewed
Apr 9, 2026
Contributor
|
Aside from the spurious extra blank line, I'm happy with these. I am, however, nervous about the proposed reversion of 8633b35 - I only see one other read of LAN88XX_INT_STS, and that is conditional on |
…PHYs" This reverts commit bd61974.
Add brcm,powerdown-enable to the external PHY nodes on Pi 4B and CM4. This puts the BCM54210PE PHY into a low-power state when the link is down, reducing power consumption when no cable is connected. This is the same approach already used by Pi 5 and CM5. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
This reverts commit 712989f.
This reverts commit 09d1901.
This reverts commit dfad8d6.
Contributor
Author
That's why I wanted to check beforehand. I will try to build a regression setup and test with and without. But this can be merged in a follow-up PR. The downshift patches [1] have also been merged, so we can revert the downstream equivalent in the future too. [1] https://lore.kernel.org/all/20260329224202.500229-1-nb@tipi-net.de/ |
nbuchwitz
force-pushed
the
devel/lan78xx-eee
branch
from
0d85bf0 to
f9ce828
Compare
This reverts commit abe92ec.
This reverts commit 9c78c6d.
This reverts commit 98fb76f.
…-broken Remove the downstream microchip,eee-enabled and microchip,tx-lpi-timer properties from the Pi 3B+ PHY node. These were consumed by the downstream lan78xx driver patches which have been reverted now that upstream (since v6.17) integrates EEE via the phylink LPI API with eee_enabled_default=true and lpi_timer_default=50. Replace the eee dtparam with standard eee-broken-1000t/eee-broken-100tx properties. Setting dtparam=eee=off adds the eee-broken properties to prevent EEE negotiation. EEE is enabled by default. Drop the tx_lpi_timer dtparam as the LPI timer is now managed by phylink and configurable via ethtool --set-eee. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
nbuchwitz
force-pushed
the
devel/lan78xx-eee
branch
from
f9ce828 to
53dc136
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The downstream
microchip,eee-enabledandmicrochip,tx-lpi-timerDT properties and the corresponding driver-side get/set_eee changes are superseded by Oleksij Rempel's proper phylink LPI integration that landed in 6.17 (673d455). That series addsmac_enable_tx_lpi/mac_disable_tx_lpicallbacks, setseee_enabled_default = trueandlpi_timer_default = 50, so EEE works out of the box without any downstream driver patches.This reverts both downstream driver patches and converts the DT to use standard
eee-broken-*PHY properties (same approach as the genet EEE cleanup in 54a9cd7), keeping the dtparam=eee=off` override working for users who need to disable EEE.Also reverts the downstream
SOF_TIMESTAMPING_TX_SOFTWAREpatch which added a duplicateget_ts_infoentry - the same fix was upstreamed independently in v6.0 (33e6b16), leaving a harmless but confusing duplicate in the ethtool_ops struct.8633b35 ("lan78xx: Ack pending PHY ints when resetting") is also a candidate for revert, as the phylink refactoring reworked the IRQ ack path. @pelwell, thoughts?