Hi Dave, Daniel,
Fixes for 5.9.
The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:
Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.9-2020-09-03
for you to fetch changes up to fc8c70526bd30733ea8667adb8b8ffebea30a8ed:
drm/radeon: Prefer lower feedback dividers (2020-09-03 00:37:30 -0400)
----------------------------------------------------------------
amd-drm-…
[View More]fixes-5.9-2020-09-03:
amdgpu:
- Fix for 32bit systems
- SW CTF fix
- Update for Sienna Cichlid
- CIK bug fixes
radeon:
- PLL fix
----------------------------------------------------------------
Evan Quan (1):
drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp setting
Jiansong Chen (1):
drm/amd/pm: enable MP0 DPM for sienna_cichlid
Kai-Heng Feng (1):
drm/radeon: Prefer lower feedback dividers
Kevin Wang (1):
drm/amd/pm: fix is_dpm_running() run error on 32bit system
Sandeep Raghuraman (2):
drm/amdgpu: Specify get_argument function for ci_smu_funcs
drm/amdgpu: Fix bug in reporting voltage for CIK
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 10 +++++++---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++-
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c | 14 ++++++++++++--
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 10 +++++++---
drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c | 14 ++++++++++----
drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 2 ++
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
7 files changed, 41 insertions(+), 14 deletions(-)
[View Less]
This adds modifier support to radeonsi.
It has been tested on
- VEGA10, RAVEN, NAVI14
- weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works)
and includes some basic testing of the layout code.
The main goal is to keep it somewhat simple and regression free, so
on the display side this series only exposes what the current GPU
can render to. While we could expose more I think that is more
suitable for follow-up work as the benefit would be minimal and
there are some more …
[View More]design discussion there to discuss that are
orthogonal from the initial implementation.
Similarly this series only exposes 32-bpp displayable DCC in the cases
that radeonsi would use it and any extra capabilities here should be
future work.
I believe these are by far the most complicated modifiers we've seen
up till now, mostly related to
- GPU identification for cases where it matters wrt tiling.
- Every generation having tiling layout changes
- Compression settings.
I believe the complexity is necessary as every layout should be different
and all layouts should be the best in some situation (though not all
combinations of GPU parameters will actually have an existing GPU).
That said, on the render side the number of modifiers actually listed for
a given GPU is ~10, and in the current implementation that is the same
for the display side. (we could expose more actually differing layouts
on the display side for cross-GPU compatibility, but I consider that
out of scope for this initial work).
This series can be found on
https://github.com/BNieuwenhuizen/linux/tree/modifiers
An userspace implementation in radeonsi can be found on
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6176
Bas Nieuwenhuizen (8):
drm/amd/display: Do not silently accept DCC for multiplane formats.
drm/amd: Init modifier field of helper fb.
drm/amd/display: Honor the offset for plane 0.
drm/fourcc: Add AMD DRM modifiers.
drm/amd/display: Refactor surface tiling setup.
drm/amd/display: Set DC options from modifiers.
drm/amd/display: Add formats for DCC with 2/3 planes.
drm/amd/display: Expose modifiers.
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 758 +++++++++++++++---
include/uapi/drm/drm_fourcc.h | 115 +++
3 files changed, 775 insertions(+), 100 deletions(-)
--
2.28.0
[View Less]
Hi everyone,
Here's a (pretty long) series to introduce support in the VC4 DRM driver
for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
The main differences are that there's two HDMI controllers and that there's
more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
have only 3 FIFOs. Both of those differences are breaking a bunch of
expectations in the driver, so we first need a good bunch of cleanup and
reworks to introduce support for the new …
[View More]controllers.
Similarly, the HDMI controller has all its registers shuffled and split in
multiple controllers now, so we need a bunch of changes to support this as
well.
Only the HDMI support is enabled for now (even though the DPI and DSI
outputs have been tested too).
Let me know if you have any comments
Maxime
Cc: bcm-kernel-feedback-list(a)broadcom.com
Cc: devicetree(a)vger.kernel.org
Cc: Kamal Dasu <kdasu.kdev(a)gmail.com>
Cc: linux-clk(a)vger.kernel.org
Cc: Michael Turquette <mturquette(a)baylibre.com>
Cc: Philipp Zabel <p.zabel(a)pengutronix.de>
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: Stephen Boyd <sboyd(a)kernel.org>
Changes from v3:
- Rebased on top of next-20200708
- Added a name to the HDMI audio codec component
- Only disable the BCM2711 HDMI pixelvalves at boot
- Fixed an error in the HVS binding
- Fix a framebuffer size condition that was inverted
- Changed the channel allocation algorithm using Eric's suggestion
- Always write the muxing values instead of updating if needed
- Improved a bit the hvs_available_channels comment in the structure
- Change atomic_complete_commit code to use for_each_new_crtc_in_state
- Change the muxing code to take into account disparities between the
BCM2711 and previous SoCs.
- Only change the clock rate on BCM2711 during a modeset
- Fix a crash at atomic_disable
- Use clk_set_min_rate for the core clock too
- Add a few defines, and simplify the FIFO level stuff
- Reordered the patches according to Eric's reviews
- Fixed a regression with VID_CTL setting on RPI3
Changes from v2:
- Rebased on top of next-20200526
- Split the firmware clock series away
- Removed the stuck pixel (with all the subsequent pixels being shifted
by one
- Fixed the writeback issue too.
- Fix the dual output
- Fixed the return value of phy_get_cp_current
- Enhanced the comment on the reset delay
- Increase the max width and height
- Made a proper Kconfig option for the DVP clock driver
- Fixed the alsa card name collision
Changes from v1:
- Rebased on top of 5.7-rc1
- Run checkpatch
- Added audio support
- Fixed some HDMI timeouts
- Swiched to clk_hw_register_gate_parent_data
- Reorder Kconfig symbols in drivers/i2c/busses
- Make the firmware clocks a child of the firmware node
- Switch DVP clock driver to clk_hw interface
- constify raspberrypi_clk_data in raspberrypi_clock_property
- Don't mark firmware clocks as IGNORE_UNUSED
- Change from reset_ms to reset_us in reset-simple, and add a bit more
comments
- Remove generic clk patch to test if a NULL pointer is returned
- Removed misleading message in the is_prepared renaming patch commit
message
- Constify HDMI controller variants
- Fix a bug in the allocation size of the clk data array
- Added a mention in the DT binding conversion patches about the breakage
- Merged a few fixes from kbuild
- Fixed a few bisection and CEC build issues
- Collected Acked-by and Reviewed-by
- Change Dave email address to raspberrypi.com
Dave Stevenson (7):
drm/vc4: Add support for the BCM2711 HVS5
drm/vc4: plane: Change LBM alignment constraint on LBM
drm/vc4: plane: Optimize the LBM allocation size
drm/vc4: hdmi: Use reg-names to retrieve the HDMI audio registers
drm/vc4: hdmi: Reset audio infoframe on encoder_enable if previously streaming
drm/vc4: hdmi: Set the b-frame marker to the match ALSA's default.
drm/vc4: hdmi: Add audio-related callbacks
Maxime Ripard (71):
dt-bindings: display: Add support for the BCM2711 HVS
drm/vc4: hvs: Boost the core clock during modeset
drm/vc4: plane: Create more planes
drm/vc4: crtc: Deal with different number of pixel per clock
drm/vc4: crtc: Use a shared interrupt
drm/vc4: crtc: Move the cob allocation outside of bind
drm/vc4: crtc: Rename HVS channel to output
drm/vc4: crtc: Use local chan variable
drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
drm/vc4: kms: Convert to for_each_new_crtc_state
drm/vc4: crtc: Assign output to channel automatically
drm/vc4: crtc: Add FIFO depth to vc4_crtc_data
drm/vc4: crtc: Add function to compute FIFO level bits
drm/vc4: crtc: Rename HDMI encoder type to HDMI0
drm/vc4: crtc: Add HDMI1 encoder type
drm/vc4: crtc: Disable color management for HVS5
drm/vc4: crtc: Turn pixelvalve reset into a function
drm/vc4: crtc: Move PV dump to config_pv
drm/vc4: crtc: Move HVS init and close to a function
drm/vc4: crtc: Move the HVS gamma LUT setup to our init function
drm/vc4: hvs: Make sure our channel is reset
drm/vc4: crtc: Remove mode_set_nofb
drm/vc4: crtc: Remove redundant pixelvalve reset
drm/vc4: crtc: Move HVS channel init before the PV initialisation
drm/vc4: encoder: Add finer-grained encoder callbacks
drm/vc4: crtc: Add a delay after disabling the PixelValve output
drm/vc4: crtc: Clear the PixelValve FIFO on disable
drm/vc4: crtc: Clear the PixelValve FIFO during configuration
drm/vc4: hvs: Make the stop_channel function public
drm/vc4: hvs: Introduce a function to get the assigned FIFO
drm/vc4: crtc: Move the CRTC disable out
drm/vc4: drv: Disable the CRTC at boot time
dt-bindings: display: vc4: pv: Add BCM2711 pixel valves
drm/vc4: crtc: Add BCM2711 pixelvalves
drm/vc4: hdmi: Use debugfs private field
drm/vc4: hdmi: Move structure to header
drm/vc4: hdmi: rework connectors and encoders
drm/vc4: hdmi: Remove DDC argument to connector_init
drm/vc4: hdmi: Rename hdmi to vc4_hdmi
drm/vc4: hdmi: Move accessors to vc4_hdmi
drm/vc4: hdmi: Use local vc4_hdmi directly
drm/vc4: hdmi: Add container_of macros for encoders and connectors
drm/vc4: hdmi: Pass vc4_hdmi to CEC code
drm/vc4: hdmi: Retrieve the vc4_hdmi at unbind using our device
drm/vc4: hdmi: Remove vc4_dev hdmi pointer
drm/vc4: hdmi: Remove vc4_hdmi_connector
drm/vc4: hdmi: Introduce resource init and variant
drm/vc4: hdmi: Implement a register layout abstraction
drm/vc4: hdmi: Add reset callback
drm/vc4: hdmi: Add PHY init and disable function
drm/vc4: hdmi: Add PHY RNG enable / disable function
drm/vc4: hdmi: Add a CSC setup callback
drm/vc4: hdmi: Store the encoder type in the variant structure
drm/vc4: hdmi: Deal with multiple debugfs files
drm/vc4: hdmi: Move CEC init to its own function
drm/vc4: hdmi: Add CEC support flag
drm/vc4: hdmi: Remove unused CEC_CLOCK_DIV define
drm/vc4: hdmi: Rename drm_encoder pointer in mode_valid
drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
drm/vc4: hdmi: Use clk_set_min_rate instead
drm/vc4: hdmi: Deal with multiple ALSA cards
drm/vc4: hdmi: Remove register dumps in enable
drm/vc4: hdmi: Always recenter the HDMI FIFO
drm/vc4: hdmi: Implement finer-grained hooks
drm/vc4: hdmi: Do the VID_CTL configuration at once
drm/vc4: hdmi: Switch to blank pixels when disabled
drm/vc4: hdmi: Support the BCM2711 HDMI controllers
dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
dt-bindings: display: vc4: Document BCM2711 VC5
drm/vc4: drv: Support BCM2711
ARM: dts: bcm2711: Enable the display pipeline
Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 +++++-
Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml | 18 +-
Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml | 5 +-
Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 1 +-
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 46 ++-
arch/arm/boot/dts/bcm2711.dtsi | 115 ++++-
drivers/gpu/drm/vc4/Makefile | 1 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 338 +++++++++++----
drivers/gpu/drm/vc4/vc4_drv.c | 5 +-
drivers/gpu/drm/vc4/vc4_drv.h | 43 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 1625 +++++++++++++++++++++++++++++++++++++++++++-----------------------------
drivers/gpu/drm/vc4/vc4_hdmi.h | 183 ++++++++-
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 520 +++++++++++++++++++++++-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 442 ++++++++++++++++++++-
drivers/gpu/drm/vc4/vc4_hvs.c | 260 +++++++-----
drivers/gpu/drm/vc4/vc4_kms.c | 225 +++++++++-
drivers/gpu/drm/vc4/vc4_plane.c | 222 +++++++---
drivers/gpu/drm/vc4/vc4_regs.h | 177 +++-----
drivers/gpu/drm/vc4/vc4_txp.c | 4 +-
19 files changed, 3331 insertions(+), 1008 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.h
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_phy.c
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_regs.h
base-commit: 5bdd2824d705fb8d339d6f96e464b907c9a1553d
--
git-series 0.9.1
[View Less]
On Tue, Sep 1, 2020 at 4:24 AM Christoph Hellwig <hch(a)lst.de> wrote:
>
> I've applied this to the dma-mapping tree.
>
> I had to resolve a conflict in drivers/of/address.c with a recent
> mainline commit. I also applied the minor tweaks Andy pointed out
> plus a few more style changes. A real change is that I changed the
> prototype for dma_copy_dma_range_map to require less boilerplate code.
>
> The result is here:
>
> http://git.infradead.org/…
[View More]users/hch/dma-mapping.git/commitdiff/eef520b232c60…
>
> please double check that everyting works as expected.
Tested-by: Jim Quinlan <james.quinlan(a)broadcom.com>
Thanks Christoph
Jim
>
> I can cut a stable branch with this if you need it for other trees, but
> I'd like to wait a few days to see if there is any fallout first.
[View Less]
Hi,
On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski <steev(a)gentoo.org> wrote:
>
> Hi Doug,
>
> I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and with this patch applied, there is really bad banding on the display.
>
> I'm really bad at explaining it, but you can see the differences in the following:
>
> 24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg
>
> 18bit (5.8/linux-next) - https://dev.gentoo.org/~steev/files/image1.…
[View More]jpg
Presumably this means that your panel is defined improperly? If the
panel reports that it's a 6 bits per pixel panel but it's actually an
8 bits per pixel panel then you'll run into this problem.
I would have to assume you have a bunch of out of tree patches to
support your hardware since I don't see any device trees in linuxnext
(other than cheza) that use this bridge chip. Otherwise I could try
to check and confirm that was the problem.
-Doug
[View Less]
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
v2: -Few patches have been squashed and patches have been shuffled as
per the reviews on the previous version.
v3: -Few patches have been squashed and patches have been shuffled as
per the reviews on the previous version.
v4: -Made changes to fix …
[View More]the sequence and time stamp issue as per the
comments received on the previous version.
-Timestamps are calculated using the flip done time stamp and current
timestamp. Here I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag is used
for timestamp calculations.
-Event is sent from the interrupt handler immediately using this
updated timestamps and sequence.
-Added more state checks as async flip should only allow change in plane
surface address and nothing else should be allowed to change.
-Added a separate plane hook for async flip.
-Need to find a way to reject fbc enabling if it comes as part of this
flip as bspec states that changes to FBC are not allowed.
v5: -Fixed the Checkpatch and sparse warnings.
v6: -Reverted back to the old timestamping code as per the feedback received.
-Added documentation.
Test-with: <20200806132935.23293-1-karthik.b.s(a)intel.com>
Karthik B S (7):
drm/i915: Add enable/disable flip done and flip done handler
drm/i915: Add support for async flips in I915
drm/i915: Add checks specific to async flips
drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
drm/i915: Add dedicated plane hook for async flip case
Documentation/gpu: Add asynchronous flip documentation for i915
drm/i915: Enable async flips in i915
Documentation/gpu/i915.rst | 6 +
drivers/gpu/drm/i915/display/intel_display.c | 127 +++++++++++++++++++
drivers/gpu/drm/i915/display/intel_sprite.c | 33 ++++-
drivers/gpu/drm/i915/i915_irq.c | 52 ++++++++
drivers/gpu/drm/i915/i915_irq.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
6 files changed, 220 insertions(+), 1 deletion(-)
--
2.22.0
[View Less]
In function via_mem_alloc`s error branch, DRM_ERROR is protected
in the mutex_lock(&dev->struct_mutex) area.
From the code, we see that DRM_ERROR is just an error log print
without any struct element, there is no need to protect this.
Signed-off-by: Bernard Zhao <bernard(a)vivo.com>
---
drivers/gpu/drm/via/via_mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/via/via_mm.c b/drivers/gpu/drm/via/via_mm.c
index 45cc9e900260..dae1bacd86c1 100644
…
[View More]--- a/drivers/gpu/drm/via/via_mm.c
+++ b/drivers/gpu/drm/via/via_mm.c
@@ -129,9 +129,9 @@ int via_mem_alloc(struct drm_device *dev, void *data,
mutex_lock(&dev->struct_mutex);
if (0 == ((mem->type == VIA_MEM_VIDEO) ? dev_priv->vram_initialized :
dev_priv->agp_initialized)) {
+ mutex_unlock(&dev->struct_mutex);
DRM_ERROR
("Attempt to allocate from uninitialized memory manager.\n");
- mutex_unlock(&dev->struct_mutex);
return -EINVAL;
}
--
2.26.2
[View Less]